Benutzerhandbuch
Version 1.9 — Rev. 3

# Virtueller Host - Sicherheit

### CAPTCHA-Schutz

#### Beschreibung

CAPTCHA Protection ist ein Dienst zur Minderung hoher Serverlast. CAPTCHA Protection wird aktiviert, sobald eine der folgenden Situationen eintritt. Sobald aktiv, werden alle Anfragen von NON TRUSTED(wie konfiguriert) Clients auf eine CAPTCHA-Validierungsseite umgeleitet. Nach der Validierung wird der Client auf die gewuenschte Seite weitergeleitet.
Die folgenden Situationen aktivieren CAPTCHA Protection:
1. Die Anzahl gleichzeitiger Anfragen des Servers oder vhost ueberschreitet das konfigurierte Verbindungslimit.
2. Anti-DDoS ist aktiviert und ein Client greift in verdaechtiger Weise auf eine url zu. Der Client wird zuerst zu CAPTCHA umgeleitet, statt bei Ausloesung abgelehnt zu werden.
3. Eine neue rewrite rule-Umgebung wird bereitgestellt, um CAPTCHA ueber RewriteRules zu aktivieren. 'verifycaptcha' kann gesetzt werden, um Clients zu CAPTCHA umzuleiten. Ein Spezialwert ': deny' kann gesetzt werden, um den Client abzulehnen, wenn er zu oft fehlgeschlagen ist. Beispiel: [E=verifycaptcha] leitet immer zu CAPTCHA um, bis die Verifizierung erfolgt. [E=verifycaptcha: deny] leitet zu CAPTCHA um, bis Max Tries erreicht ist; danach wird der Client abgelehnt.

### CAPTCHA aktivieren

#### Beschreibung

Aktiviert die Funktion CAPTCHA Protection auf der aktuellen Ebene. Diese Einstellung muss auf Serverebene auf Yes gesetzt sein, bevor CAPTCHA Protection verwendet werden kann.
Standardwerte:
Serverebene: Yes
VH-Ebene: Einstellung der Serverebene übernehmen

#### Syntax

Aus Optionsfeldern auswählen

### Site Key

#### Beschreibung

Der öffentliche Schlüssel, der von reCAPTCHA- oder hCaptcha-Diensten zugewiesen wird.
Bei Verwendung von reCAPTCHA wird ein Standard-Site-Key verwendet, wenn keiner gesetzt ist (nicht empfohlen).

### Secret Key

#### Beschreibung

Der private Schlüssel, der von reCAPTCHA- oder hCaptcha-Diensten zugewiesen wird.
Bei Verwendung von reCAPTCHA wird ein Standard-Secret-Key verwendet, wenn keiner gesetzt ist (nicht empfohlen).

### CAPTCHA-Typ

#### Beschreibung

Gibt den CAPTCHA-Typ an, der mit den Schlüsselpaaren verwendet wird.
Wenn kein Schlüsselpaar bereitgestellt wurde und diese Einstellung auf Not Set gesetzt ist, wird ein Standard-Schlüsselpaar des CAPTCHA-Typs reCAPTCHA Invisible verwendet.
reCAPTCHA Checkbox zeigt dem Besucher ein Checkbox-CAPTCHA zur Validierung an. (erfordert Site Key, Secret Key)
reCAPTCHA Invisible versucht, das CAPTCHA automatisch zu validieren, und leitet bei Erfolg zur gewünschten Seite weiter. (erfordert Site Key, Secret Key)
hCaptcha kann verwendet werden, um den CAPTCHA-Anbieter hCaptcha zu unterstützen. (erfordert Site Key, Secret Key)
Standardwert ist reCAPTCHA Invisible.

#### Syntax

Aus Dropdown-Liste auswählen

### Max. Versuche

#### Beschreibung

Max Tries gibt die maximale Anzahl zulässiger CAPTCHA-Versuche an, bevor der Besucher abgewiesen wird.
Standardwert ist 3.

#### Syntax

Ganzzahl

### Grenze gleichzeitiger Anfragen

#### Beschreibung

Die Anzahl gleichzeitiger Anfragen, die zum Aktivieren von CAPTCHA erforderlich ist. CAPTCHA wird weiter verwendet, bis die Anzahl gleichzeitiger Anfragen unter diese Zahl faellt.
Standardwert ist 15000.

#### Syntax

Ganzzahl

### Bubblewrap-Container

#### Beschreibung

Setzen Sie dies auf Enabled, wenn Sie CGI-Prozesse (einschließlich PHP-Programme) in einer bubblewrap-Sandbox starten möchten. Siehe https://wiki.archlinux.org/title/Bubblewrap für Details zur Verwendung von bubblewrap. Bubblewrap muss auf Ihrem System installiert sein, bevor Sie diese Einstellung verwenden.
Diese Einstellung kann auf Virtual-Host-Ebene nicht eingeschaltet werden, wenn sie auf Serverebene auf "Disabled" gesetzt ist.
Standardwerte:
Serverebene: Disabled
VH-Ebene: Einstellung der Serverebene übernehmen

#### Syntax

Aus Dropdown-Liste auswählen

### Namespace-Container

#### Beschreibung

Setzen Sie dies auf Enabled, wenn Sie CGI-Prozesse (einschließlich PHP-Programme) in einer Namespace-Container-Sandbox starten möchten. Wird nur verwendet, wenn Bubblewrap-Container auf Disabled gesetzt ist.
Wenn diese Einstellung auf Serverebene nicht Disabled ist, kann ihr Wert auf Virtual-Host-Ebene überschrieben werden.
Standardwerte:
Serverebene: Disabled
Virtual-Host-Ebene: Einstellung der Serverebene übernehmen

#### Syntax

Aus Dropdown-Liste auswählen

### Zusaetzliche Namespace-Vorlagendatei

#### Beschreibung

Pfad zu einer vorhandenen Konfigurationsdatei mit einer Liste von Verzeichnissen, die zusammen mit den verwendeten Mount-Methoden eingehangen werden sollen. Wenn Namespace-Vorlagendatei auch auf Serverebene gesetzt ist, werden beide Dateien verwendet.

#### Syntax

Ein Pfad, der absolut, relativ zu $SERVER_ROOT oder relativ zu $VH_ROOT sein kann.

### Zugriffskontrolle

#### Beschreibung

Gibt an, welche Subnetze und/oder IP-Adressen auf den Server zugreifen koennen. Auf Serverebene wirkt sich diese Einstellung auf alle virtuellen Hosts aus. Sie koennen auch eine eigene Zugriffskontrolle fuer jeden virtuellen Host auf Virtual-Host-Ebene einrichten. Einstellungen auf Virtual-Host-Ebene ueberschreiben Server-Level-Einstellungen NICHT.
Das Blockieren/Erlauben einer IP wird durch die Kombination aus erlaubter Liste und verweigerter Liste bestimmt. Wenn Sie nur bestimmte IPs oder Subnetze blockieren moechten, setzen Sie * oder ALL in Erlaubte Liste und listen die blockierten IPs oder Subnetze in Verweigerte Liste. Wenn Sie nur bestimmte IPs oder Subnetze erlauben moechten, setzen Sie * oder ALL in Verweigerte Liste und listen die erlaubten IPs oder Subnetze in Erlaubte Liste. Die Einstellung des kleinsten passenden Geltungsbereichs wird verwendet, um den Zugriff zu bestimmen.
Serverebene: Vertrauenswuerdige IPs oder Subnetze muessen in Erlaubte Liste durch Anhaengen eines abschliessenden "T" angegeben werden. Vertrauenswuerdige IPs oder Subnetze sind nicht von Verbindungs-/Throttling-Limits betroffen. Nur die Zugriffskontrolle auf Serverebene kann vertrauenswuerdige IPs/Subnetze einrichten.

#### Tipps

Security Verwenden Sie dies auf Serverebene fuer allgemeine Einschraenkungen, die fuer alle virtuellen Hosts gelten.

### Erlaubte Liste

#### Beschreibung

Gibt die Liste erlaubter IPs oder Subnetze an. * oder ALL werden akzeptiert.

#### Syntax

Kommagetrennte Liste von IP-Adressen oder Subnetzen. Ein abschließendes "T" kann verwendet werden, um eine vertrauenswürdige IP oder ein vertrauenswürdiges Subnetz anzugeben, zum Beispiel 192.168.1.*T.

#### Beispiel

Subnetze: 192.168.1.0/255.255.255.0, 192.168.1.0/24, 192.168.1, oder 192.168.1.*
IPv6-Adressen: ::1 oder [::1]
IPv6-Subnetze: 3ffe:302:11:2:20f:1fff:fe29:717c/64 oder [3ffe:302:11:2:20f:1fff:fe29:717c]/64

#### Tipps

Security Vertrauenswürdige IPs oder Subnetze, die in der Zugriffskontrolle auf Serverebene gesetzt sind, werden von Verbindungs-/Throttling-Limits ausgenommen.

### Verweigerte Liste

#### Beschreibung

Gibt die Liste nicht erlaubter IPs oder Subnetze an.

#### Syntax

Kommagetrennte Liste von IP-Adressen oder Subnetzen. * oder ALL werden akzeptiert.

#### Beispiel

Subnetze: 192.168.1.0/255.255.255.0, 192.168.1.0/24, 192.168.1, oder 192.168.1.*
IPv6-Adressen: ::1 oder [::1]
IPv6-Subnetze: 3ffe:302:11:2:20f:1fff:fe29:717c/64 oder [3ffe:302:11:2:20f:1fff:fe29:717c]/64

### Autorisierungs-Realms

#### Beschreibung

Listet alle Autorisierungs-Realms fuer diesen virtuellen Host auf. Autorisierungs-Realms werden verwendet, um nicht autorisierte Benutzer am Zugriff auf geschuetzte Webseiten zu hindern. Ein Realm ist ein Benutzerverzeichnis mit Benutzernamen und Passwoertern sowie optionalen Gruppeneinteilungen. Die Autorisierung erfolgt auf Kontextebene. Da verschiedene Kontexte denselben Realm (Benutzerdatenbank) gemeinsam nutzen koennen, werden Realms getrennt von den Kontexten definiert, die sie verwenden. Sie koennen in der Kontextkonfiguration mit diesen Namen auf einen Realm verweisen.

### Realm-Name

#### Beschreibung

Gibt einen eindeutigen Namen fuer den Autorisierungs-Realm an.

### Speicherort der Benutzer-DB

#### Beschreibung

Gibt den Speicherort der Benutzerdatenbank an. Es wird empfohlen, die Datenbank im Verzeichnis $SERVER_ROOT/conf/vhosts/$VH_NAME/ zu speichern.
Beim DB-Typ Password File ist dies der Pfad zur Flatfile mit Benutzer-/Passwortdefinitionen. Sie koennen diese Datei ueber die WebAdmin-Konsole bearbeiten, indem Sie auf den Dateinamen klicken.
Jede Zeile der Benutzerdatei enthaelt einen Benutzernamen, gefolgt von einem Doppelpunkt, gefolgt von einem mit crypt() verschluesselten Passwort, optional gefolgt von einem Doppelpunkt und den Gruppennamen, zu denen der Benutzer gehoert. Gruppennamen werden durch Kommas getrennt. Wenn Gruppeninformationen in der Benutzerdatenbank angegeben sind, wird die Gruppendatenbank nicht geprueft.
Beispiel:

> `john:HZ.U8kgjnMOHo:admin,user`

#### Syntax

Pfad zur Benutzer-DB-Datei.

#### Siehe auch

Speicherort der Gruppen-DB, Passwortattribut, Member-of-Attribut

### Maximale Cachegroesse der Benutzer-DB

#### Beschreibung

Gibt die maximale Cachegroesse der Benutzerdatenbank an. Kuerzlich verwendete Benutzerauthentifizierungsdaten werden fuer maximale Leistung im Speicher zwischengespeichert.

#### Syntax

Ganzzahl

#### Tipps

Performance Da ein groesserer Cache mehr Speicher verbraucht, kann ein hoeherer Wert bessere Leistung bieten oder auch nicht. Setzen Sie ihn entsprechend der Groesse Ihrer Benutzerdatenbank und der Nutzung der Site auf eine passende Groesse.

### Cache-Timeout der Benutzer-DB (Sek.)

#### Beschreibung

Gibt an, wie oft die Backend-Benutzerdatenbank auf Aenderungen geprueft wird. Jeder Cacheeintrag hat einen Zeitstempel. Wenn zwischengespeicherte Daten aelter als das angegebene Timeout sind, wird die Backend-Datenbank auf Aenderungen geprueft. Gibt es keine Aenderung, wird der Zeitstempel auf die aktuelle Zeit zurueckgesetzt; andernfalls werden die neuen Daten geladen. Server-Neuladen und graceful restart leeren den Cache sofort.

#### Syntax

Ganzzahl

#### Tipps

Performance Wenn sich die Backend-Datenbank nicht sehr haeufig aendert, setzen Sie fuer bessere Leistung ein laengeres Timeout.

### Speicherort der Gruppen-DB

#### Beschreibung

Gibt den Speicherort der Gruppendatenbank an. Es wird empfohlen, die Datenbank im Verzeichnis $SERVER_ROOT/conf/vhosts/$VH_NAME/ zu speichern.
Gruppeninformationen koennen entweder in der Benutzerdatenbank oder in dieser eigenstaendigen Gruppen-DB festgelegt werden. Fuer die Benutzerauthentifizierung wird zuerst die Benutzer-DB geprueft. Wenn die Benutzer-DB ebenfalls Gruppeninformationen enthaelt, wird die Gruppen-DB nicht geprueft.
Beim DB-Typ Password File sollte der Speicherort der Gruppen-DB der Pfad zur Flatfile mit Gruppendefinitionen sein. Sie koennen diese Datei ueber die WebAdmin-Konsole bearbeiten, indem Sie auf den Dateinamen klicken.
Jede Zeile einer Gruppendatei sollte einen Gruppennamen enthalten, gefolgt von einem Doppelpunkt und einer durch Leerzeichen getrennten Gruppe von Benutzernamen. Beispiel:

> `testgroup: user1 user2 user3`

#### Syntax

Dateiname, der ein absoluter Pfad oder ein Pfad relativ zu $SERVER_ROOT, $VH_ROOT sein kann.

#### Siehe auch

Speicherort der Benutzer-DB, Context Require (autorisierte Benutzer/Gruppen), Gruppenmitglied-Attribut

### Maximale Cachegroesse der Gruppen-DB

#### Beschreibung

Gibt die maximale Cachegroesse der Gruppendatenbank an.

#### Syntax

Ganzzahl

#### Tipps

Performance Da ein groesserer Cache mehr Speicher verbraucht, kann ein hoeherer Wert bessere Leistung bieten oder auch nicht. Setzen Sie ihn entsprechend der Groesse Ihrer Benutzerdatenbank und der Nutzung der Site auf eine passende Groesse.

#### Siehe auch

Maximale Cachegroesse der Benutzer-DB

### Cache-Timeout der Gruppen-DB (Sek.)

#### Beschreibung

Gibt an, wie oft die Backend-Gruppendatenbank auf Aenderungen geprueft wird. Weitere Details finden Sie unter Cache-Timeout der Benutzer-DB (Sek.).

#### Syntax

Ganzzahl

#### Siehe auch

Cache-Timeout der Benutzer-DB (Sek.)