Traffic-Filterregeln, einschließlich WAF-Regeln traffic-filter-rules-including-waf-rules
Traffic-Filterregeln können verwendet werden, um Anforderungen auf der CDN-Ebene zu blockieren oder zuzulassen. Dies kann in Szenarien wie den folgenden nützlich sein:
- Einschränken des Zugriffs auf bestimmte Domains auf den internen Unternehmensdatenverkehr, bevor eine neue Site live geschaltet wird
- Festlegen von Ratenbeschränkungen, um für volumetrische DoS-Angriffe weniger anfällig zu sein
- Verhindern, dass IP-Adressen, die als bösartig bekannt sind, auf Ihre Seiten zugreifen.
Die meisten dieser Traffic-Filterregeln stehen allen Kundinnen und Kunden von AEM as a Cloud Service Sites und Forms zur Verfügung. Sie arbeiten hauptsächlich mit den Eigenschaften und Kopfzeilen von Anfragen, einschließlich IP, Host-Name, Pfad und Benutzeragent.
Eine Unterkategorie von Traffic-Filterregeln erfordert entweder eine Lizenz für erweiterte Sicherheit oder eine WAF-DDoS Protection-Lizenz. Diese leistungsstarken Regeln werden als Traffic-Filterregeln für WAF (Web Application Firewall, kurz: WAF-Regeln) bezeichnet und haben Zugriff auf die WAF-Flags, die weiter unten in diesem Artikel beschrieben werden.
Traffic-Filterregeln können über Cloud Manager-Konfigurations-Pipelines in Entwicklungs-, Staging- und Produktionsumgebungen in Produktionsprogrammen (ohne Sandbox) bereitgestellt werden. Die Konfigurationsdatei kann mithilfe der Befehlszeilenwerkzeuge in Rapid Developement Environments (RDEs) bereitgestellt werden.
Durchlaufen Sie ein Tutorial, um rasch konkrete Kenntnisse zu dieser Funktion zu erwerben.
Wie dieser Artikel organisiert ist how-organized
Dieser Artikel ist in die folgenden Abschnitte unterteilt:
- Traffic-Schutz – Übersicht: Erfahren Sie, wie Sie vor schädlichem Traffic geschützt werden.
- Empfohlener Prozess zum Konfigurieren von Regeln: Erfahren Sie mehr über allgemeine Methoden zum Schutz Ihrer Website.
- Setup: Erfahren Sie, wie Sie Traffic-Filterregeln einrichten, konfigurieren und bereitstellen, einschließlich der erweiterten WAF-Regeln.
- Regelsyntax: Erfahren Sie, wie Sie Traffic-Filterregeln in der Konfigurationsdatei von
cdn.yaml
deklarieren. Dazu gehören sowohl die Traffic-Filterregeln, die für alle Kundinnen und Kunden von Sites und Forms verfügbar sind, als auch die Unterkategorie der WAF-Regeln für diejenigen, die diese Funktion lizenzieren. - Regelbeispiele: Sehen Sie sich zu Beginn Beispiele für deklarierte Regeln an.
- Ratenbegrenzungsregeln: Erfahren Sie, wie Sie Regeln zur Ratenbegrenzung verwenden, um Ihre Site vor Angriffen mit hohem Volumen zu schützen.
- Warnhinweise zu Traffic-Filterregeln: Konfigurieren Sie Warnhinweise, um benachrichtigt zu werden, wenn Ihre Regeln ausgelöst werden.
- Warnhinweis zu Standard-Traffic-Spitze am Ursprung: Lassen Sie sich benachrichtigen, wenn ein Anstieg des Traffics am Ursprung auf einen DDoS-Angriff hindeutet.
- CDN-Protokolle: Erfahren Sie, welche deklarierten Regeln und WAF-Flags mit Ihrem Traffic übereinstimmen.
- Dashboard-Tooling: Analysieren Sie Ihre CDN-Protokolle, um neue Traffic-Filterregeln zu erstellen.
- Empfohlene Anfangsregeln: Ein Regelsatz für die ersten Schritte.
- Tutorial: Praktisches Wissen bezüglich der Funktion, einschließlich der Verwendung der Dashboard-Werkzeuge zum Deklarieren der richtigen Regeln.
Adobe lädt Sie ein, Feedback zu geben oder Fragen zu Traffic-Filterregeln zu stellen, indem Sie eine E-Mail an aemcs-waf-adopter@adobe.com senden.
Traffic-Schutz – Übersicht traffic-protection-overview
In der aktuellen digitalen Landschaft stellt schädlicher Traffic eine immer präsente Bedrohung dar. Adobe ist sich der Ernsthaftigkeit des Risikos bewusst und bietet verschiedene Ansätze zum Schutz von Kundenanwendungen und zur Eindämmung von Angriffen.
Am Edge absorbiert das von Adobe verwaltete CDN DoS-Angriffe auf der Netzwerkschicht (Ebene 3 und 4), einschließlich Angriffe durch Überschwemmung oder Reflexion/Verstärkung.
Adobe ergreift standardmäßig Maßnahmen, um eine Leistungsbeeinträchtigung durch unerwartet hohes Traffic-Aufkommen über einen bestimmten Schwellenwert hinaus zu verhindern. Im Falle eines DoS-Angriffs, der die Verfügbarkeit der Website beeinträchtigt, werden die Betriebs-Teams von Adobe benachrichtigt und Maßnahmen zur Eindämmung des Problems ergriffen.
Kundinnen und Kunden können proaktive Maßnahmen ergreifen, um Angriffe auf Anwendungsebene (Ebene 7) zu minimieren, indem sie Regeln auf verschiedenen Ebenen des Inhaltsbereitstellungsflusses konfigurieren.
Auf der Apache-Ebene können Kundinnen und Kunden beispielsweise das Dispatcher-Modul oder ModSecurity konfigurieren, um den Zugriff auf bestimmte Inhalte zu beschränken.
Wie in diesem Artikel beschrieben, können Traffic-Filterregeln auf dem von Adobe verwalteten CDN bereitgestellt werden. Verwendet werden dazu die in Cloud Manager verfügbaren Konfigurations-Pipelines. Zusätzlich zu Traffic-Filterregeln, die auf Eigenschaften wie IP-Adresse, Pfad und Headern basieren, oder Regeln, die auf der Festlegung von Ratenbeschränkungen beruhen, können Kundinnen und Kunden auch eine leistungsstarke Unterkategorie von Traffic-Filterregeln lizenzieren, die sogenannten WAF-Regeln.
Vorgeschlagener Prozess suggested-process
Im Folgenden finden Sie einen allgemein empfohlenen End-to-End-Prozess für die Erstellung der richtigen Traffic-Filterregeln:
- Konfigurieren Sie Konfigurations-Pipelines für Nicht-Produktion und Produktion, wie im Abschnitt Einrichtung beschrieben.
- Kundinnen und Kunden, die die Unterkategorie der WAF-Traffic-Filterregeln lizenziert haben, sollten sie in Cloud Manager aktivieren.
- Lesen und probieren Sie das Tutorial aus, um genau zu verstehen, wie Traffic-Filterregeln verwendet werden, einschließlich WAF-Regeln, wenn sie lizenziert wurden. Das Tutorial führt Sie durch die Bereitstellung von Regeln in einer Entwicklungsumgebung, die Simulation von schädlichem Traffic sowie den Download der CDN-Protokolle und ihre Analyse in den Dashboard-Tools.
- Kopieren Sie die empfohlenen Anfangsregeln nach
cdn.yaml
und stellen Sie die Konfiguration in der Produktionsumgebung im Protokollmodus bereit. - Nachdem Sie etwas Traffic erfasst haben, analysieren Sie die Ergebnisse mit den Dashboard-Tools, um zu sehen, ob es Übereinstimmungen gab. Suchen Sie nach Falsch-Positiv-Werten und nehmen Sie die erforderlichen Anpassungen vor, um schließlich die Anfangsregeln im Blockmodus zu aktivieren.
- Fügen Sie benutzerdefinierte Regeln hinzu, die auf der Analyse der CDN-Protokolle basieren. Testen Sie sie zunächst mit simuliertem Traffic in Entwicklungsumgebungen, bevor Sie sie in Staging- und Produktionsumgebungen im Protokollmodus und dann im Blockmodus bereitstellen.
- Überwachen Sie den Traffic auf fortlaufender Basis und nehmen Sie Änderungen an den Regeln vor, wenn sich die Bedrohungslage weiterentwickelt.
Einrichtung setup
-
Erstellen Sie eine Datei
cdn.yaml
mit einer Reihe von Traffic-Filterregeln, einschließlich WAF-Regeln.code language-none kind: "CDN" version: "1" metadata: envTypes: ["dev"] data: trafficFilters: rules: # Block simple path - name: block-path when: allOf: - reqProperty: tier matches: "author|publish" - reqProperty: path equals: '/block/me' action: block
Eine Beschreibung der Eigenschaften oberhalb des Knotens
data
finden Sie unter Verwenden von Konfigurations-Pipelines. Der Eigenschaftswertkind
sollte auf CDN und die Version auf1
festgelegt werden. -
Wenn WAF-Regeln lizenziert sind, sollten Sie die Funktion in Cloud Manager aktivieren, wie unten für sowohl neue als auch bestehende Programmszenarien beschrieben.
-
Um WAF in einem neuen Programm zu konfigurieren, markieren Sie das Kontrollkästchen WAF-DDOS-Schutz auf der Registerkarte Sicherheit, wenn Sie ein Produktionsprogramm hinzufügen.
-
Um WAF für ein vorhandenes Programm zu konfigurieren, können Sie jederzeit Ihr Programm bearbeiten und auf der Registerkarte Sicherheit die Option WAF-DDOS deaktivieren oder aktivieren.
-
-
Erstellen Sie in Cloud Manager eine Konfigurations-Pipeline. Folgen Sie dabei den Anweisungen im Artikel zu Konfigurations-Pipelines. Die Pipeline verweist auf einen Ordner der obersten Ebene mit dem Namen
config
. Die Dateicdn.yaml
ist in der Hierarchie darunter abgelegt, siehe Verwenden von Konfigurations-Pipelines.
Syntax für Traffic-Filterregeln rules-syntax
Sie können Traffic-Filterregeln konfigurieren, um Übereinstimmungen mit Mustern wie IPs, Benutzeragent, Anfrage-Headern, Host-Name, Geo und URL zu erhalten.
Kundinnen und Kunden mit einer Lizenz für die erweiterte Sicherheit oder die Sicherheitsoption zum Schutz vor WAF-DDoS können auch eine spezielle Kategorie von Traffic-Filterregeln namens WAF-Traffic-Filterregeln (oder kurz: WAF-Regeln) konfigurieren, die auf eine oder mehrere WAF-Flags verweisen.
Im Folgenden finden Sie ein Beispiel für einen Satz von Traffic-Filterregeln, der auch eine WAF-Regel enthält.
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "path-rule"
when:
allOf:
- { reqProperty: path, equals: /block-me }
- { reqProperty: tier, equals: publish }
action:
type: block
- name: "Enable-SQL-Injection-and-XSS-waf-rules-globally"
when: { reqProperty: path, like: "*" }
action:
type: block
wafFlags: [ SQLI, XSS]
Das Format der Traffic-Filterregeln in der Datei cdn.yaml
wird im Folgenden beschrieben. Siehe einige andere Beispiele in einem späteren Abschnitt sowie einen separaten Abschnitt zu Ratenbegrenzungsregeln.
string
Condition
{ <getter>: <value>, <predicate>: <value> }
Siehe Syntax für Bedingungsstruktur weiter unten, in dem die Getter, Eigenschaften und die Kombination mehrerer Bedingungen beschrieben werden.
Action
RateLimit
Weiter unten finden Sie einen separaten Abschnitt mit einer Beschreibung der rateLimit-Syntax sowie Beispiele.
Bedingungsstruktur condition-structure
Eine Bedingung kann entweder eine einfache Bedingung oder eine Gruppe von Bedingungen sein.
Einfache Bedingung
Eine einfache Bedingung besteht aus einem Getter und einem Prädikat.
{ <getter>: <value>, <predicate>: <value> }
Gruppenbedingungen
Eine Gruppe von Bedingungen besteht aus mehreren einfachen und/oder Gruppenbedingungen.
<allOf|anyOf>:
- { <getter>: <value>, <predicate>: <value> }
- { <getter>: <value>, <predicate>: <value> }
- <allOf|anyOf>:
- { <getter>: <value>, <predicate>: <value> }
array[Condition]
array[Condition]
Getter
string
Anfrageeigenschaft.
Eines von:
path
: Gibt den vollständigen Pfad einer URL ohne die Abfrageparameter zurück.queryString
: Gibt den Abfrageteil einer URL zurückmethod
: Gibt die in der Anfrage verwendete HTTP-Methode zurück.tier
: Gibt entwederauthor
,preview
oderpublish
zurück.domain
: Gibt die Eigenschaft der Domain (wie in derHost
-Kopfzeile definiert) in Kleinschreibung zurückclientIp
: Gibt die Client-IP zurück.clientCountry
: Gibt einen aus zwei Buchstaben bestehenden Code (Regionales Indikatorsymbol) zurück, der angibt, in welchem Land sich die Kundin bzw. der Kunde befindet.
string
string
string
string
application/x-www-form-urlencoded
istPrädikat
string
string
string
string
string
string
array[string]
array[string]
boolean
Anmerkungen
- Die Anfrageeigenschaft
clientIp
kann nur mit den folgenden Prädikaten verwendet werden:equals
,doesNotEqual
,in
,notIn
.clientIp
kann bei auch mit IP-Bereichen verglichen werden, wenn die Prädikatein
undnotIn
verwendet werden. Im folgenden Beispiel wird eine Bedingung implementiert, um zu bewerten, ob eine Client-IP im IP-Bereich von 192.168.0.0/24 liegt (also von 192.168.0.0 bis 192.168.0.255):
when:
reqProperty: clientIp
in: [ "192.168.0.0/24" ]
- Adobe empfiehlt die Verwendung von regex101 und Fastly Fiddle bei der Arbeit mit Regex. Weitere Informationen darüber, wie Fastly mit Regex umgeht, finden Sie in der Fastly-Dokumentation – Reguläre Ausdrücke in Fastly VCL.
Aktionsstruktur action-structure
Ein action
kann entweder eine Zeichenfolge sein, die die Aktion angibt (Zulassen, Blockieren oder Protokollieren), oder ein Objekt, das sowohl aus dem Aktionstyp (Zulassen, Blockieren oder Protokollieren) als auch aus Optionen wie wafFlags und/oder dem Status besteht.
Aktionstypen
Aktionen werden entsprechend ihren Typen in der folgenden Tabelle priorisiert, die entsprechend der Reihenfolge sortiert ist, in der die Aktionen ausgeführt werden.
wafFlags
(optional), alert
(optional)Falls ein Warnhinweis angegeben wird, wird eine Benachrichtigung des Aktionszentrums gesendet, wenn die Regel zehnmal innerhalb eines 5-minütigen Zeitfensters ausgelöst wird. Sobald ein Warnhinweis für eine bestimmte Regel ausgelöst wurde, wird er erst am nächsten Tag (UTC) wieder ausgelöst.
status, wafFlags
(optional und sich gegenseitig ausschließend), alert
(optional)Falls ein Warnhinweis angegeben wird, wird eine Benachrichtigung des Aktionszentrums gesendet, wenn die Regel zehnmal innerhalb eines 5-minütigen Zeitfensters ausgelöst wird. Sobald ein Warnhinweis für eine bestimmte Regel ausgelöst wurde, wird er erst am nächsten Tag (UTC) wieder ausgelöst.
wafFlags
(optional), alert
(optional)Falls ein Warnhinweis angegeben wird, wird eine Benachrichtigung des Aktionszentrums gesendet, wenn die Regel zehnmal innerhalb eines 5-minütigen Zeitfensters ausgelöst wird. Sobald ein Warnhinweis für eine bestimmte Regel ausgelöst wurde, wird er erst am nächsten Tag (UTC) wieder ausgelöst.
WAF-Flags-Liste waf-flags-list
Die wafFlags
-Eigenschaft, die in den lizenzierbaren WAF-Traffic-Filterregeln verwendet werden kann, kann auf Folgendes verweisen:
/bin/
CMDEXE
, während falsch positive Ergebnisse für /bin
aufgrund der AEM-Architektur deaktiviert werden./foo/./bar
wird normalisiert in /foo/bar
).htaccess
-Datei oder eine Konfigurationsdatei, der vertrauliche Informationen entnommen werden könnten.Überlegungen considerations
-
Wenn zwei in Konflikt stehende Regeln erstellt werden, haben die Zulassungsregeln immer Vorrang vor den Blockierungsregeln. Wenn Sie beispielsweise eine Regel erstellen, die einen bestimmten Pfad blockiert, und eine Regel, die eine bestimmte IP-Adresse zulässt, sind Anfragen von dieser IP-Adresse auf dem blockierten Pfad zulässig.
-
Wenn eine Regel abgeglichen und blockiert wird, antwortet das CDN mit einem
406
-Rückgabe-Code. -
Die Konfigurationsdateien sollten keine Geheimnisse enthalten, da sie von allen Benutzenden gelesen werden können, die Zugriff auf das Git-Repository haben.
-
In Cloud Manager definierte IP-Zulassungslisten haben Vorrang vor Traffic-Filterregeln.
-
Übereintimmungen für eine WAF-Regel erscheinen nur in CDN-Protokollen bei Fehlschlägen und Durchgängen von CDN, nicht jedoch bei Treffern.
Regelbeispiele examples
Es folgen einige Regelbeispiele. Weitere Informationen zu Beispielen für Ratenbegrenzungsregeln finden Sie weiter unten im Abschnitt Ratenbegrenzung.
Beispiel 1
Diese Regel blockiert Anfragen von der IP 192.168.1.1:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "block-request-from-ip"
when: { reqProperty: clientIp, equals: "192.168.1.1" }
action:
type: block
Beispiel 2
Diese Regel blockiert Anfragen auf dem Pfad /helloworld
bei Veröffentlichung mit einem Benutzeragenten, der Chrome umfasst:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "block-request-from-chrome-on-path-helloworld-for-publish-tier"
when:
allOf:
- { reqProperty: path, equals: /helloworld }
- { reqProperty: tier, equals: publish }
- { reqHeader: user-agent, matches: '.*Chrome.*' }
action:
type: block
Beispiel 3
Diese Regel blockiert Anfragen bei der Veröffentlichung, die den Abfrageparameter foo
enthalten, erlaubt jedoch jede Anfrage von der IP 192.168.1.1:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "block-request-that-contains-query-parameter-foo"
when:
allOf:
- { queryParam: url-param, equals: foo }
- { reqProperty: tier, equals: publish }
action:
type: block
- name: "allow-all-requests-from-ip"
when: { reqProperty: clientIp, equals: 192.168.1.1 }
action:
type: allow
Beispiel 4
Diese Regel blockiert Anfragen bei der Veröffentlichung an den Pfad /block-me
und blockiert alle Anfragen, die mit einem SQLI
- oder XSS
-Muster übereinstimmen. Dieses Beispiel enthält eine WAF-Traffic-Filterregel, die auf WAF-Flags SQLI
und XSS
verweist und daher eine separate Lizenz erfordert.
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "path-rule"
when:
allOf:
- { reqProperty: path, equals: /block-me }
- { reqProperty: tier, equals: publish }
action:
type: block
- name: "Enable-SQL-Injection-and-XSS-waf-rules-globally"
when: { reqProperty: path, like: "*" }
action:
type: block
wafFlags: [ SQLI, XSS]
Beispiel 5
Diese Regel blockiert den Zugriff auf OFAC-Länder:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: block-ofac-countries
when:
allOf:
- reqProperty: tier
matches: "author|publish"
- reqProperty: clientCountry
in:
- SY
- BY
- MM
- KP
- IQ
- CD
- SD
- IR
- LR
- ZW
- CU
- CI
action: block
Ratenbegrenzungsregeln
Manchmal ist es wünschenswert, Traffic zu blockieren, wenn er eine bestimmte Rate eingehender Anfragen überschreitet, basierend auf einer bestimmten Bedingung. Wenn Sie einen Wert für die Eigenschaft rateLimit
festlegen, wird die Rate der Anfragen, die mit der Regelbedingung übereinstimmen, begrenzt.
Ratenbegrenzungsregeln können nicht auf WAF-Flags verweisen. Sie stehen allen Kundinnen und Kunden von Sites und Forms zur Verfügung.
Die Ratenbegrenzungen werden pro CDN-POP berechnet. Nehmen wir zum Beispiel an, dass die POPs in Montreal, Miami und Dublin eine Traffic-Rate von 80, 90 bzw. 120 Anfragen pro Sekunde haben. Außerdem ist die Regel zur Begrenzung der Rate auf einen Grenzwert von 100 festgelegt. In diesem Fall würde nur der Traffic nach Dublin begrenzt.
Ratenbegrenzungen werden entweder anhand von Traffic bewertet, der am Edge ankommt bzw. der am Ursprung ankommt, oder anhand der Anzahl der Fehler.
rateLimit-Struktur ratelimit-structure
Beispiele ratelimiting-examples
Beispiel 1
Diese Regel blockiert einen Client für 5 Millisekunden, wenn er in den letzten 10 Sekunden durchschnittlich 60 Anfragen/Sek. (pro CDN-POP) überschreitet:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: limit-requests-client-ip
when:
reqProperty: tier
matches: "author|publish"
rateLimit:
limit: 60
window: 10
penalty: 300
count: all
groupBy:
- reqProperty: clientIp
action: block
Beispiel 2
Blockiert Anfragen für 60 Sekunden für den Pfad „/critical/resource“, wenn in einem Zeitfenster von zehn Sekunden durchschnittlich 100 Anfragen pro Sekunde an den Ursprung (pro CDN-POP) überschritten werden:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: rate-limit-example
when:
allOf:
- { reqProperty: path, equals: /critical/resource }
- { reqProperty: tier, equals: publish }
action:
type: block
rateLimit: { limit: 100, window: 10, penalty: 60, count: fetches }
CVE-Regeln cve-rules
Wenn WAF lizenziert ist, wendet Adobe automatisch Blockierungsregeln an, um vor vielen bekannten CVEs (Common Vulnerabilities and Exposures) zu schützen, und neue CVEs können kurz nach ihrer Entdeckung hinzugefügt werden. Kundinnen und Kunden sollten CVE-Regeln nicht selbst konfigurieren und brauchen es auch nicht.
Wenn eine Traffic-Anfrage einer CVE entspricht, wird sie im entsprechenden CDN-Protokolleintrag angezeigt.
Wenden Sie sich an den Adobe-Support, wenn Sie Fragen zu einer bestimmten CVE haben oder wenn eine bestimmte CVE-Regel vorliegt, die Ihre Organisation deaktivieren möchte.
Warnhinweise für Traffic-Filterregeln traffic-filter-rules-alerts
Eine Regel kann so konfiguriert werden, dass eine Benachrichtigung des Aktionszentrums gesendet wird, wenn sie innerhalb eines 5-minütigen Fensters zehnmal ausgelöst wird. Eine solche Regel warnt Sie, wenn bestimmte Traffic-Muster auftreten, sodass Sie die erforderlichen Maßnahmen treffen können. Sobald ein Warnhinweis für eine bestimmte Regel ausgelöst wurde, wird er erst am nächsten Tag (UTC) wieder ausgelöst.
Erfahren Sie mehr über das Aktionszentrum, einschließlich der Einrichtung der erforderlichen Benachrichtigungsprofile für den Empfang von E-Mails.
Die Eigenschaft „Warnhinweis“ kann für alle Aktionstypen (allow, block, log) auf den Knoten „Aktion“ angewendet werden.
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "path-rule"
when:
allOf:
- { reqProperty: path, equals: /block-me }
- { reqProperty: tier, equals: publish }
action:
type: block
alert: true
Standard-Warnhinweis zu Traffic-Spitze am Ursprung traffic-spike-at-origin-alert
Eine E-Mail-Benachrichtigung des Aktionszentrums wird gesendet, wenn eine signifikante Menge an Traffic zum Ursprung gesendet wird, bei der eine hohe Anzahl von Anfragen von derselben IP-Adresse kommt, was auf einen DDoS-Angriff hindeutet.
Wenn dieser Schwellenwert erreicht wird, blockiert Adobe den Traffic von dieser IP-Adresse. Es wird jedoch empfohlen, zusätzliche Maßnahmen zu ergreifen, um Ihren Ursprung zu schützen, einschließlich der Konfiguration von Traffic-Filterregeln zur Ratenbegrenzung, um Traffic-Spitzen bei niedrigeren Schwellenwerten zu blockieren. Weitere Informationen finden Sie im Tutorial zum Blockieren von DoS- und DDoS-Angriffen mithilfe von Traffic-Regeln, das Sie durch die einzelnen Schritte führt.
Dieser Warnhinweis ist standardmäßig aktiviert, kann aber durch Festlegen der Eigenschaft defaultTrafficAlerts auf „falsch“ deaktiviert werden. Sobald der Warnhinweis ausgelöst wurde, wird er erst wieder am nächsten Tag (UTC) ausgelöst.
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
defaultTrafficAlerts: false
CDN-Protokolle cdn-logs
AEM as a Cloud Service bietet Zugriff auf CDN-Protokolle, die für Anwendungsfälle nützlich sind, einschließlich der Optimierung der Cache-Trefferquote und der Konfiguration von Traffic-Filterregeln. CDN-Protokolle werden im Cloud Manager-Dialog Protokolle herunterladen angezeigt, wenn Sie den Author- oder Publish-Service auswählen.
CDN-Protokolle können sich bis zu fünf Minuten verzögern.
Die Eigenschaft rules
beschreibt, welche Traffic-Filterregeln übereinstimmen, und weist folgendes Muster auf:
"rules": "match=<matching-customer-named-rules-that-are-matched>,waf=<matching-WAF-rules>,action=<action_type>"
Beispiel:
"rules": "match=Block-Traffic-under-private-folder,Enable-SQL-injection-everywhere,waf="SQLI,SANS",action=block"
Die Regeln verhalten sich wie folgt:
- Der auf Kundenseite deklarierte Regelname aller übereinstimmenden Regeln wird im Attribut
match
aufgeführt. - Das Attribut
action
bestimmt, ob die Regeln etwas blockieren, erlauben oder protokollieren. - Wenn die WAF lizenziert und aktiviert ist, listet das Attribut
waf
alle WAF-Flags (z. B. SQLI) auf, die entdeckt wurden. Dies gilt unabhängig davon, ob die WAF-Flags in Regeln aufgeführt wurden. Dies soll Aufschluss über potenzielle neue Regeln geben, die deklariert werden können. - Wenn keine auf Kundenseite deklarierten Regeln übereinstimmen und keine WAF-Regeln übereinstimmen, ist die Eigenschaft
rules
leer.
Wie bereits erwähnt, erscheinen Übereinstimmungen für eine WAF-Regel nur in CDN-Protokollen für Fehlschläge und Durchgänge von CDN, nicht jedoch für Treffer.
Das folgende Beispiel zeigt eine beispielhafte cdn.yaml
und zwei CDN-Protokolleinträge:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "path-rule"
when: { reqProperty: path, equals: /block-me }
action: block
- name: "Enable-SQL-Injection-and-XSS-waf-rules-globally"
when: { reqProperty: path, like: "*" }
action:
type: block
wafFlags: [ SQLI, XSS ]
{
"timestamp": "2023-05-26T09:20:01+0000",
"ttfb": 19,
"cli_ip": "147.160.230.112",
"cli_country": "CH",
"rid": "974e67f6",
"req_ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15",
"host": "example.com",
"url": "/block-me",
"method": "GET",
"res_ctype": "",
"cache": "PASS",
"status": 406,
"res_age": 0,
"pop": "PAR",
"rules": "match=path-rule,action=blocked"
}
{
"timestamp": "2023-05-26T09:20:01+0000",
"ttfb": 19,
"cli_ip": "147.160.230.112",
"cli_country": "CH",
"req_ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15",
"rid": "974e67f6",
"host": "example.com",
"url": "/?sqli=%27%29%20UNION%20ALL%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL--%20fAPK",
"method": "GET",
"res_ctype": "image/png",
"cache": "PASS",
"status": 406,
"res_age": 0,
"pop": "PAR",
"rules": "match=Enable-SQL-Injection-and-XSS-waf-rules-globally,waf=SQLI,action=blocked"
}
Protokollformat cdn-log-format
Nachfolgend finden Sie eine Liste der in CDN-Protokollen verwendeten Feldnamen sowie eine kurze Beschreibung.
Gibt auch an, ob die Übereinstimmung zu einer Blockierung führte.
Beispiel: „
match=Enable-SQL-Injection-and-XSS-waf-rules-globally,waf=SQLI,action=blocked
“Leer, wenn keine Regeln übereinstimmten.
Dashboard-Tools dashboard-tooling
Adobe bietet einen Mechanismus zum Herunterladen von Dashboard-Tools auf Ihren Computer, um CDN-Protokolle zu erfassen, die über Cloud Manager heruntergeladen wurden. Mit diesen Tools können Sie Ihren Traffic analysieren, um die entsprechenden Traffic-Filterregeln zu finden, die deklariert werden können, einschließlich WAF-Regeln.
Dashboard-Tools können direkt aus dem GitHub-Repository AEMCS-CDN-Log-Analysis-Tooling heruntergeladen werden.
Für konkrete Anweisungen zum Verwenden der Dashboard-Tools verfügbar sind Tutorials verfügbar.
Empfohlene Anfangsregeln recommended-starter-rules
Sie können für den Anfang die folgenden empfohlenen Regeln in Ihre cdn.yaml
kopieren. Starten Sie im Protokollmodus, analysieren Sie Ihren Traffic und wechseln Sie, wenn Sie zufrieden sind, in den Blockierungsmodus. Sie können die Regeln auf Grundlage der einzigartigen Merkmale des Live-Traffics Ihrer Website ändern.
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev", "stage", "prod"]
data:
trafficFilters:
rules:
# Block client for 5m when it exceeds an average of 100 req/sec to origin on a time window of 10sec
- name: limit-origin-requests-client-ip
when:
reqProperty: tier
equals: 'publish'
rateLimit:
limit: 100
window: 10
count: fetches
penalty: 300
groupBy:
- reqProperty: clientIp
action: log
# Block client for 5m when it exceeds an average of 500 req/sec on a time window of 10sec
- name: limit-requests-client-ip
when:
reqProperty: tier
equals: 'publish'
rateLimit:
limit: 500
window: 10
count: all
penalty: 300
groupBy:
- reqProperty: clientIp
action: log
# Block requests coming from OFAC countries
- name: block-ofac-countries
when:
allOf:
- { reqProperty: tier, in: ["author", "publish"] }
- reqProperty: clientCountry
in:
- SY
- BY
- MM
- KP
- IQ
- CD
- SD
- IR
- LR
- ZW
- CU
- CI
action: log
# Enable recommended WAF protections (only works if WAF is licensed enabled for your environment)
- name: block-waf-flags-globally
when:
reqProperty: tier
in: ["author", "publish"]
action:
type: log
wafFlags:
- TRAVERSAL
- CMDEXE-NO-BIN
- XSS
- LOG4J-JNDI
- BACKDOOR
- USERAGENT
- SQLI
- SANS
- TORNODE
- NOUA
- SCANNER
- PRIVATEFILE
- NULLBYTE
Tutorials tutorial
Zwei Tutorials sind verfügbar.
Schutz von Websites mit Traffic-Filterregeln (einschließlich WAF-Regeln) tutorial-protecting-websites
Arbeiten Sie ein Tutorial durch, um allgemeine, praktische Kenntnisse und Erfahrungen im Zusammenhang mit Traffic-Filterregeln zu sammeln, einschließlich WAF-Regeln.
Das Tutorial führt Sie durch folgende Themen:
- Einrichten der Konfigurations-Pipeline für Cloud Manager
- Verwenden von Tools zur Simulation von schädlichem Traffic
- Definieren von Traffic-Filterregeln, einschließlich WAF-Regeln
- Analyse von Ergebnissen mit Dashboard-Tools
- Best Practices
Blockieren von DoS- und DDoS-Angriffen mithilfe von Traffic-Filterregeln tutorial-blocking-DDoS-with-rules
Umfassende Informationen zum Blockieren von DoS- (Denial of Service) und DDoS-Angriffen (Distributed Denial of Service) mithilfe von Traffic-Filterregeln mit Ratenbegrenzungen und anderen Strategien.
Das Tutorial führt Sie durch folgende Themen:
- Grundlegendes zum Schutz
- Erhalten von Warnungen beim Überschreiten von Ratenbegrenzungen
- Analysieren von Traffic-Mustern mithilfe von Dashboard-Tools, um Schwellenwerte für Traffic-Filterregeln mit Ratenbegrenzungen zu konfigurieren