Nginx Reverse Proxy für VPN-losen Zugriff auf Cisco Finesse konfigurieren (12.6 ES03)

Einleitung

In diesem Dokument wird die Verwendung eines Reverse-Proxys für den Zugriff auf den Cisco Finesse-Desktop beschrieben, ohne eine Verbindung zu einem VPN herzustellen, das auf den 12.6 ES03-Versionen von Cisco Finesse, Cisco Unified Intelligence Center (CUIC) und Cisco Identity Service (IdS) basiert.

Hinweis: Die Installation und Konfiguration von Nginx wird von Cisco nicht unterstützt. Fragen zu diesem Thema können in den Cisco Community-Foren diskutiert werden.

Hinweis: Bei ES03-Bereitstellungen von VPN-Less finden Sie die Readme-Datei der einzelnen Komponenten, um die Upgrades zu planen und Kompatibilitätseinschränkungen zu überprüfen. Cisco Finesse 12.6 ES03 Readme, CUIC / IdS 12.6 ES03 Readme

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Version Cisco Unified Contact Center Enterprise (UCCE)
• Cisco Finesse
• Linux-Administration
• Netzwerkadministration und Linux Netzwerkadministration

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Finesse - 12,6 ES03
• CUIC - 12,6 ES03
• IDs - 12.6 ES03
• UCCE/Hosted Collaboration Solution (HCS) für Contact Center (CC) - 11.6 oder höher
• Packaged Contact Center Enterprise (PCCE) - 12.5 oder höher
  
  Hinweis: PCCE/UCCE 2k-Bereitstellungen müssen aufgrund der gemeinsamen Bereitstellung von LD/CUIC auf der 12.6-Version von CCE erfolgen.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hinweis: Die in diesem Dokument beschriebene Konfiguration wurde mit Nginx Reverse Proxy (OpenResty) auf CentOS 8.0 konfiguriert, gehärtet und hinsichtlich der Auslastung mit einer UCCE-Beispielbereitstellung für 2.000 Benutzer getestet. Informationen zu Leistungsprofilen finden Sie in diesem Dokument.

Hintergrundinformationen

Dieses Bereitstellungsmodell wird für UCCE-/PCCE- und HCS-Lösungen für UCCE unterstützt.

Die Bereitstellung eines Reverse-Proxys wird unterstützt (erhältlich ab 12.6 ES01) und ermöglicht den Zugriff auf den Cisco Finesse Desktop ohne VPN-Verbindung. Diese Funktion bietet den Agenten die Flexibilität, von überall über das Internet auf den Finesse-Desktop zuzugreifen.

Um diese Funktion zu aktivieren, muss ein Reverse Proxy-Paar in der DMZ (Demilitarized Zone) bereitgestellt werden.

Bei Reverse-Proxy-Bereitstellungen bleibt der Medienzugriff unverändert. Zur Verbindung mit den Medien können Mitarbeiter die Cisco Jabber over Mobile and Remote Access-Lösung (MRA) oder die Mobile Agent-Funktion von UCCE mit einem öffentlichen Telefonnetz (Public Switched Telefone Network, PSTN) oder einem mobilen Endgerät verwenden. Dieses Diagramm zeigt, wie die Netzwerkbereitstellung aussehen wird, wenn Sie über ein einzelnes hochverfügbares Paar von Reverse Proxy-Knoten auf zwei Finesse-Cluster und zwei CUIC-Knoten zugreifen.

Der gleichzeitige Zugriff von Agenten im Internet und Agenten, die sich über das LAN verbinden, wird unterstützt, wie in diesem Bild gezeigt.

Hinweis: Informationen zur Unterstützung dieser Bereitstellung finden Sie im Funktionsleitfaden für die Auswahl von Drittanbieter-Proxys anstelle von Nginx.

- UCCE 12.6-Funktionshandbuch - Bietet eine Funktionsübersicht, ein Design sowie Konfigurationsdetails für die Funktion ohne VPN.
- UCCE 12.6 Security Guide (Sicherheitsleitfaden) - Stellt Sicherheitskonfigurationsrichtlinien für die Reverse Proxy-Bereitstellung bereit.

Es wird empfohlen, den Abschnitt "VPN-Less" im Funktionsleitfaden und im Sicherheitsleitfaden zu lesen, bevor Sie dieses Dokument lesen.

Änderungen in ES03

• Neue Funktionen
  
  
  • Finesse Supervisor-Funktionen werden nun über Reverse Proxy unterstützt.
  • CUIC RealTime- und Verlaufsberichte werden jetzt über Finesse-Gadgets in einer Proxyumgebung unterstützt.
    
    
  • Authentifizierung für alle Anfragen/Mitteilungen - Lua-Unterstützung erforderlich
    
    • Alle Finesse-/CUIC-/IM&P-Anfragen (IM&P) werden auf dem Proxy authentifiziert, bevor sie in das Rechenzentrum eindringen dürfen.
    • Websocket und Live Data SocketIO-Verbindungen sind ebenfalls eingeschränkt und nur von Clients erlaubt, die erfolgreich eine gesicherte Anfrage an Finesse gestellt haben.
    • Brute-Force-Erkennung und -Protokollierung am Proxy, die mit Fail2Ban verwendet werden kann, um schädliche IP-Adressen zu blockieren.
      
      
• Sicherheitserweiterungen für Reverse Proxy-Konfiguration - Lua-Unterstützung erforderlich
  
  • Gegenseitige Transport Layer Security (TLS)-Authentifizierung zwischen Reverse Proxy und Upstream-Komponenten (Finesse/IdS/CUIC/Livedata).
  • Siehe Linux-Einstellungen.
  • Aktivieren Sie die gegenseitige Überprüfung der Secure Sockets Layer (SSL)-Vertrauenswürdigkeit für Proxy- und Komponentenserveranforderungen.
    
    
• Erhöhte Sicherheit für die Proxy-Konfiguration zur Verhinderung von Denial-of-Service (DoS)-/Distributed-Denial-of-Service (DDoS)-Angriffen - Lua-Unterstützung erforderlich
  
  • Erweiterte Nginx-Anforderungsratenbeschränkungen für verschiedene Teile des Systems.
  • Ratenbegrenzungen für IP-Tabellen.
  • Überprüfen statischer Ressourcenanforderungen vor Anforderung des Upstream-Komponentenservers.
  • Leichtere und zwischenspeicherbare, nicht authentifizierte Seiten, die den Upstream-Komponentenserver nicht erreichen.
    
    
• Verschiedene andere Funktionen - Lua-Unterstützung erforderlich
  • Vom Proxy bereitgestellte automatische Abtastung der CORS-Antworten (Cross-Origin Resource Sharing) zur Unterstützung der automatischen Konfiguration und zur Verbesserung der Leistung
    
    
• Behebung von Fehlern im Zusammenhang mit VPN-Less
  
  
  • CSCwa26057CSCwa26057 " />- Mehrere Zertifikate, die dem Agenten während der finesse Desktop-Anmeldung angeboten werden
  • CSCwa24471 - Auf der Anmeldeseite von Finesse wird der FQDN-Name des SSO-Agenten nicht angezeigt.
  • CSCwa24519 : Der Webproxy-Dienst kann nicht neu gestartet werden, wenn der Reverse-Proxy-Hostname nicht von der Komponente aufgelöst werden kann.
  • CSCwa23252 : Proxy-Finesse-Vertrauensstellung wird unterbrochen, wenn die Tiefe für CA-Zertifikatskette größer als eins ist
  • CSCwa46459 log4j Zero-Day-Schwachstelle im Webservice bekannt gegeben

Upgrade-Hinweise für ES01-basierte VPN-lose Konfigurationen

• ES03-Konfiguration erfordert Nginx-Installation mit Lua-Unterstützung.
• Zertifikatanforderungen
  • Für Cisco Finesse, CUIC und IdS muss das Nginx/OpenResty-Hostzertifikat zum Tomcat-Vertrauensspeicher hinzugefügt und ein Neustart durchgeführt werden, bevor die Nginx ES02-Konfiguration erfolgreich mit dem Upstream-Server verbunden werden kann.
  • Cisco Finesse-, CUIC- und IdS-Upstream-Serverzertifikate müssen auf dem Nginx-Server konfiguriert werden, um die ES03-basierte Konfiguration zu verwenden.

Hinweis: Es wird empfohlen, die vorhandene ES01-basierte Nginx-Konfiguration zu entfernen, bevor Sie die ES03 Nginx-Konfigurationen installieren.

Hinweis: ES03-Konfigurationsskripte erfordern auch die entsprechende ES03 COP-Installation in Cisco Finesse, CUIC und IdS.

Authentifizierung

Finesse 12.6 ES03 führt die Authentifizierung am Proxy ein. Die Authentifizierung wird für Single Sign On (SSO)- und Nicht-SSO-Bereitstellungen unterstützt.

Die Authentifizierung wird für alle Anforderungen und Protokolle erzwungen, die vom Proxy akzeptiert werden, bevor sie an die Upstream-Komponentenserver weitergeleitet werden, wo die von den Komponentenservern lokal erzwungene Authentifizierung ebenfalls erfolgt. Bei der Authentifizierung werden die allgemeinen Finesse-Anmeldeinformationen verwendet, um die Anforderungen zu authentifizieren.

Persistente Verbindungen, wie z. B. Websockets, die für die Authentifizierung und Nachverbindung auf Anwendungsprotokollen wie Extensible Messaging and Presence Protocol (XMPP) basieren, werden am Proxy authentifiziert, indem die IP-Adresse validiert wird, von der eine erfolgreiche Anwendungsauthentifizierung vor dem Herstellen der Socketverbindung durchgeführt wurde.

Nicht-SSO-Authentifizierung

Für die Nicht-SSO-Authentifizierung sind keine zusätzlichen Konfigurationen erforderlich. Sie funktioniert auch mit sofort einsatzbereiten Nginx-Konfigurationsskripten, sobald die erforderlichen Skriptersetzungen vorgenommen wurden. Die Authentifizierung erfolgt über den Benutzernamen und das Kennwort für die Anmeldung bei Finesse. Der Zugriff auf alle Endgeräte wird mithilfe von Finesse-Authentifizierungsservices validiert.

Die Liste der gültigen Benutzer wird lokal auf dem Proxy zwischengespeichert (aktualisiert den Cache alle 15 Minuten), der verwendet wird, um den Benutzer in einer Anforderung zu validieren. Die Benutzeranmeldeinformationen werden validiert, indem die Anforderung an den konfigurierten Finesse-URI weitergeleitet wird. Anschließend wird der Hash der Anmeldeinformationen lokal zwischengespeichert (15 Minuten zwischengespeichert), um neue Anforderungen lokal zu authentifizieren. Änderungen am Benutzernamen oder Passwort werden erst nach 15 Minuten wirksam.

SSO-Authentifizierung

Für die SSO-Authentifizierung muss der Administrator den IDs-Token-Verschlüsselungsschlüssel auf dem Nginx-Server in der Konfigurationsdatei konfigurieren. Der Schlüssel für die IdS-Tokenverschlüsselung kann vom IdS-Server mit dem CLI-Befehl show ids secret abgerufen werden. Der Schlüssel muss als Teil einer der #Must-change-Ersetzungen konfiguriert werden, die der Administrator in den Skripten durchführen muss, bevor die SSO-Authentifizierung funktionieren kann.

Informationen zu den IdS-SAML-Konfigurationen, die ausgeführt werden müssen, damit die Proxyauflösung für IdS funktioniert, finden Sie im SSO-Benutzerhandbuch.

Nach der Konfiguration der SSO-Authentifizierung kann ein gültiges Paar Token verwendet werden, um auf einen beliebigen Endpunkt im System zuzugreifen. Die Proxykonfiguration validiert die Anmeldeinformationen, indem die an IdS gesendeten Tokenabrufanforderungen abgefangen oder gültige Token entschlüsselt und anschließend lokal für weitere Validierungen zwischengespeichert werden.

Authentifizierung für Websocket-Verbindungen

Websocket-Verbindungen können nicht mit dem standardmäßigen Autorisierungsheader authentifiziert werden, da benutzerdefinierte Header von nativen Websocket-Implementierungen im Browser nicht unterstützt werden. Authentifizierungsprotokolle auf Anwendungsebene, bei denen die in der Nutzlast enthaltenen Authentifizierungsinformationen den Aufbau einer Websocket-Verbindung nicht verhindern. Daher können böswillige Einheiten DOS- oder DDOS-Angriffe auslösen, indem sie unzählige Verbindungen herstellen, um das System zu überlasten.

Um diese Möglichkeit zu entschärfen, werden in den vorgesehenen nginx-Reverse-Proxy-Konfigurationen spezifische Prüfungen durchgeführt, um zu ermöglichen, dass Websocket-Verbindungen NUR von denjenigen IP-Adressen akzeptiert werden, die vor der Herstellung der Websocket-Verbindung erfolgreich eine authentifizierte REST-Anforderung gestellt haben. Das bedeutet, dass Clients, die vor der Ausgabe einer REST-Anforderung Websocket-Verbindungen herstellen, nun einen Fehler bei der Autorisierung erhalten, der nicht mehr unterstützt wird.

Brute-Force-Schutz

Finesse 12.6 ES02-Authentifizierungs-Skripte verhindern Brute-Force-Angriffe, mit denen das Benutzerkennwort erraten werden kann. Hierzu wird die für den Zugriff auf den Dienst verwendete IP-Adresse nach einer bestimmten Anzahl fehlgeschlagener Versuche in kurzer Zeit blockiert. Diese Anfragen werden mit dem 418-Clientfehler abgelehnt. Auf die Details der gesperrten IP-Adressen können Sie aus den Dateien <nginx-install-directory>/logs/blocking.log und <nginx-install-directory>/logs/error.log zugreifen.

Die Anzahl der fehlgeschlagenen Anforderungen, das Zeitintervall und die Blockierungsdauer können konfiguriert werden. Konfigurationen sind in der Datei <nginx-install-directory>/conf/conf.d/maps.conf vorhanden.

## These two constants indicate five auth failures from a client can be allowed in thirty seconds.
## if  the threshold is crossed,client ip will be blocked.
map $host $auth_failure_threshold_for_lock {
    ## Must-change Replace below two parameters as per requirement
    default 5 ;
}

map $host $auth_failure_counting_window_secs {
    ## Must-change Replace below two parameters as per requirement
    default 30;
}

## This indicates duration of blocking a client to avoid brute force attack
map $host $ip_blocking_duration {
    ## Must-change Replace below parameter as per requirement
    default 1800;
}

Protokollieren

Um die blockierten IP-Adressen zu finden, führen Sie die folgenden Befehle aus dem Verzeichnis <nginx-install-directory>/logs aus.

grep "will be blocked for" blocking.log
grep "IP is already blocked." error.log

2021/10/29 17:30:59 [emerg] 1181750#1181750: *19 [lua] block_unauthorized_users.lua:153: 
_redirectAndSendError(): 10.68.218.190 will be blocked for 30 minutes for exceeding retry limit., 
client: 10.68.218.190, server: saproxy.cisco.com, request: 
"GET /finesse/api/SystemInfo?nocache=1636456574482 HTTP/2.0", host: "saproxy.cisco.com:8445", 
referrer: "https://saproxy.cisco.com:8445/desktop/container/?locale=en_US&"

2021/10/29 19:21:00 [error] 943068#943068: *43 [lua] block_unauthorized_users.lua:53: 10.70.235.30 :: 
IP is already blocked..., client: 10.70.235.30, server: saproxy.cisco.com, request: 
"GET /finesse/api/SystemInfo?nocache=1635591686497 HTTP/2.0", host: "saproxy.cisco.com:8445", 
referrer: "https://saproxy.cisco.com:8445/desktop/container/?locale=en_US"

Es wird empfohlen, dass Kunden Fail2ban oder Ähnliches integrieren, um das Verbot zu den IP-Tabellen/Firewall-Regeln hinzuzufügen.

Installation und Konfiguration von Fail2ban

Fail2ban scannt Protokolldateien und sperrt IPs, die schädliche Zeichen anzeigen - zu viele Passwortfehler, Exploits usw. Im Allgemeinen wird Fail2Ban dann verwendet, um Firewall-Regeln zu aktualisieren, um die IP-Adressen für einen bestimmten Zeitraum abzulehnen. Es können jedoch auch beliebige andere Aktionen (z. B. das Senden einer E-Mail) konfiguriert werden. Weitere Informationen finden Sie unter https://www.fail2ban.org/.

Fail2ban kann so konfiguriert werden, dass die Datei "blocking.log" überwacht wird, um die IP-Adressen zu identifizieren, die von Nginx bei der Erkennung von Bruteforce-Angriffen blockiert werden, und sie für einen konfigurierbaren Zeitraum zu sperren. Die Schritte zum Installieren und Konfigurieren von fail2ban auf einem CentOS-Reverseproxy sind wie folgt:

1. Installieren Sie Fail2ban mit yum.

yum update && yum install epel-release
yum install fail2ban 

2. Erstelle ein lokales Gefängnis.

Jail-Konfigurationen ermöglichen es dem Administrator, verschiedene Eigenschaften zu konfigurieren, z. B. die Ports, für die der Zugriff durch eine blockierte IP-Adresse verboten werden soll, die Dauer der Blockierung der IP-Adresse, die Filterkonfiguration zur Identifizierung der blockierten IP-Adresse aus der überwachten Protokolldatei usw. So fügen Sie eine benutzerdefinierte Konfiguration hinzu, um den Zugriff auf die Upstream-Server für blockierte IP-Adressen zu unterbinden:

2.1. Wechseln Sie zum Fail2ban-Installationsverzeichnis (in diesem Beispiel /etc/fail2ban).

cd /etc/fail2ban

2.2. Erstellen Sie eine Kopie von jail.conf in jail.local, um die lokalen Änderungen zu isolieren.

cp jail.conf jail.local 

2.3. Fügen Sie diese Jail-Konfigurationen zum Ende der Datei jail.local hinzu, und ersetzen Sie die Ports in der Vorlage durch die tatsächlichen Ports. Aktualisieren Sie ggf. die Konfigurationen für die Sperrzeit.

# Jail configurations for HTTP connections.
[finesse-http-auth]
enabled = true
# The ports to be blocked. Add any additional ports.
port = http,https,<finesse-ports>,<cuic-ports>,<any-other-ports-to-be-blocked>
# Path to nginx blocking logs.
logpath = /usr/local/openresty/nginx/logs/blocking.log
# The filter configuration.
filter = finesseban
# Block the IP from accessing the port, once the IP is blocked by lua.
maxretry= 1
# Duration for retry set to 3 mins. Doesn't count as the maxretry is 1
findtime= 180
# Lock time is set to 3 mins. Change as per requirements.
bantime = 180

3. Konfigurieren Sie einen Filter.

Ein Filter teilt Fail2ban mit, wonach in den Protokollen gesucht werden muss, um den zu sperrenden Host zu identifizieren. So erstellen Sie einen Filter:

3.1. Erstellen Sie filter.d/finesseban.conf.

touch filter.d/finesseban.conf 

3.2. Fügen Sie diese Zeilen der Datei filter.d/finesseban.conf hinzu.

[Definition]
# The regex match that would cause blocking of the host.
failregex = <HOST> will be blocked for

4. Starten Sie Fail2ban.

Führen Sie diesen Befehl aus, um fail2ban zu starten.

fail2ban-client start

Öffnen Sie fail2ban-Protokolldateien, und stellen Sie sicher, dass keine Fehler vorliegen. Standardmäßig werden Protokolle für fail2ban in die Datei /var/log/fail2ban.log aufgenommen.

Statische Ressourcen-URLs überprüfen

Alle gültigen Endpunkte, auf die nicht authentifiziert zugegriffen werden kann, werden in den ES03-Skripten aktiv nachverfolgt.

Anforderungen an diese nicht authentifizierten Pfade werden aktiv abgelehnt, wenn ein ungültiger URI angefordert wird, ohne diese Anforderungen an den Upstream-Server zu senden.

CORS-Header zwischenspeichern

Wenn die Anforderung der ersten Optionen erfolgreich war, werden die Antwort-Header "access-control-allow-headers", "access-control-allow-origine", "access-control-allow-methods", "access-control-expose-headers" und "access-control-allow-dentials" fünf Minuten lang im Proxy zwischengespeichert. Diese Header werden für jeden entsprechenden Upstream-Server zwischengespeichert.

Konfigurieren

In diesem Dokument wird die Konfiguration von Nginx als Reverse-Proxy beschrieben, der für den VPN-losen Zugriff von Finesse verwendet wird. Es werden die UCCE-Lösungskomponente, der Proxy und die Betriebssystemversionen zur Verifizierung der bereitgestellten Anweisungen bereitgestellt. Die entsprechenden Anweisungen müssen an das Betriebssystem/den Proxy Ihrer Wahl angepasst werden.

• Verwendete Nginx-Version - OpenResty 1.19.9.1
• Für die Konfiguration verwendetes Betriebssystem - CentOS 8.0

Hinweis: Die beschriebene Nginx-Konfiguration kann von der Software-Download-Seite von Finesse Release 12.6(1)ES3 heruntergeladen werden.

Lösungskomponenten für weniger VPN-Zugriff konfigurieren

Konfigurieren Sie nach der Konfiguration des Proxys die Lösungskomponenten (Finesse/CUIC/IdS) für den VPN Less-Zugriff mit dem geplanten Hostnamen und der IP-Adresse des Proxys/der Dienste, die für den Zugriff auf die Lösung mit diesen Befehlen verwendet werden.

utils system reverse-proxy allowed-hosts add
utils system reverse-proxy config-uri <uri> add

Die Details zu diesen Befehlen finden Sie im UCCE 12.6-Funktionshandbuch. Auf diese Befehle sollte vor der Verwendung dieses Dokuments näher eingegangen werden.

Installieren von OpenResty als Reverse Proxy in der DMZ

In diesem Abschnitt werden die Schritte zur OpenResty-basierten Proxy-Installation beschrieben. Der Reverse Proxy wird in der Regel als dediziertes Gerät in der demilitarisierten Netzwerkzone (DMZ) konfiguriert, wie im oben erwähnten Bereitstellungsdiagramm gezeigt.

1. Installieren Sie das Betriebssystem Ihrer Wahl mit der erforderlichen Hardware-Spezifikation. Die Kernel- und IPv4-Parameteranpassungen können je nach ausgewähltem Betriebssystem unterschiedlich sein. Benutzern wird empfohlen, diese Aspekte erneut zu überprüfen, wenn die ausgewählte Betriebssystemversion unterschiedlich ist.
2. Zwei Netzwerkschnittstellen konfigurieren. Eine Schnittstelle wird für den öffentlichen Zugriff von den Internet-Clients benötigt, eine andere für die Kommunikation mit den Servern im internen Netzwerk.
3. Installieren Sie OpenResty.

Alle Aromen von Nginx können für diesen Zweck verwendet werden, solange sie auf Nginx 1.19+ basieren und Lua unterstützen:

• Nginx Plus
• Nginx Open Source (Nginx Open Source muss zusammen mit OpenResty-basierten Lua-Modulen kompiliert werden, damit es verwendet werden kann)
• OpenResty
• GetPageSpeed-Extras

Hinweis: Die bereitgestellte Konfiguration wurde mit OpenResty 1.19 getestet und wird voraussichtlich mit anderen Distributionen mit nur geringfügigen Updates funktionieren, falls vorhanden.

OpenResty-Installation

1. Installieren Sie OpenResty. Siehe OpenResty Linux Packages. Als Teil der OpenResty-Installation wird Nginx an diesem Speicherort installiert und der PATH-Variablen den OpenResty-Pfad durch Hinzufügen in der Datei ~/.bashrc hinzugefügt.

   export PATH=/usr/local/openresty/bin:$PATH

2. Nginx starten / stoppen.
   • Um Nginx zu starten, geben Sie openrestyein.
   • Um Nginx zu stoppen, geben Sie openresty -s stopein.

Nginx konfigurieren

Die Konfiguration wird für eine OpenResty-basierte Nginx-Installation erläutert. Die Standardverzeichnisse für OpenResty sind:

• <nginx-Installationsverzeichnis> = /usr/local/openresty/nginx
• <Openresty-install-directory> = /usr/local/openresty

1. Laden Sie die Datei von der Download-Seite der Software Finesse Release 12.6(1)ES03 (12.6-ES03-reverse-proxy-config.zip) herunter und extrahieren Sie sie. Diese enthält die Reverse-Proxy-Konfiguration für Nginx.
2. Kopieren Sie nginx.conf, nginx/conf.d/ und nginx/html/ aus dem extrahierten Reverse-Proxy-Konfigurationsverzeichnis in <nginx-install-directory>/conf, <nginx-install-directory>/conf/conf.d/, und <nginx-install-directory>/html/jeweils.
3. Kopieren Sie das Verzeichnis nginx/lua aus dem extrahierten Reverse-Proxy-Konfigurationsverzeichnis in <nginx-install-directory>.
4. Kopieren Sie den Inhalt von lualib nach <Openresty-install-directory>/lualib/resty.
5. Konfigurieren Sie die Rotation des nginx-Protokolls, indem Sie die Datei nginx/logrotate/saproxy in den Ordner <nginx-install-directory>/logrotate kopieren. Ändern Sie den Dateiinhalt so, dass er auf die richtigen Protokollverzeichnisse zeigt, wenn keine Nginx-Standardwerte verwendet werden.
6. Nginx muss mit einem dedizierten, nicht privilegierten Dienstkonto ausgeführt werden, das gesperrt sein und eine ungültige Shell aufweisen muss (bzw. für das ausgewählte Betriebssystem zutreffend ist).
7. Suchen Sie die "Must-change" Zeichenkette in den Dateien unter den extrahierten Ordnern html und conf.d und ersetzen Sie die angegebenen Werte durch entsprechende Einträge.
8. Stellen Sie sicher, dass alle erforderlichen Ersetzungen vorgenommen wurden, die mit den Kommentaren Must-change in den Konfigurationsdateien beschrieben werden.
9. Stellen Sie sicher, dass die für CUIC und Finesse konfigurierten Cache-Verzeichnisse zusammen mit diesen temporären Verzeichnissen unter <nginx-install-directory>/cache erstellt werden.
   • <nginx-Installationsverzeichnis>/cache/client_temp
   • <nginx-Installationsverzeichnis>/cache/proxy_temp

Hinweis: Die bereitgestellte Konfiguration ist für eine Beispielbereitstellung im Jahr 2000 und muss für eine größere Bereitstellung entsprechend erweitert werden.

Konfigurieren des Nginx-Caches

Standardmäßig werden die Proxycachepfade im Dateisystem gespeichert. Wir empfehlen, sie in In-Memory-Laufwerke zu ändern, indem Sie einen Cache-Speicherort in tmpfs erstellen, wie hier gezeigt.

1. Erstellen Sie Verzeichnisse für die verschiedenen Proxycachepfade unter /home.

   Als Beispiel müssen diese Verzeichnisse für die primäre Finesse erstellt werden. Die gleichen Schritte müssen für die sekundären Finesse- und CUIC-Server ausgeführt werden.

   mkdir -p /home/primaryFinesse/rest
   mkdir -p /home/primaryFinesse/desktop
   mkdir -p /home/primaryFinesse/shindig
   mkdir -p /home/primaryFinesse/openfire
   mkdir -p /home/primaryCUIC/cuic
   mkdir -p /home/primaryCUIC/cuicdoc
   mkdir -p /home/client_temp
   mkdir -p /home/proxy_temp

   echo "tmpfs /home/primaryFinesse/rest tmpfs size=1510M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryFinesse/desktop tmpfs size=20M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryFinesse/shindig tmpfs size=500M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryFinesse/openfire tmpfs size=10M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryCUIC/cuic tmpfs size=100M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryCUIC/cuicdoc tmpfs size=100M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/client_temp tmpfs size=2048M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/proxy_temp tmpfs size=2048M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >> /etc/fstab

   Hinweis: Erhöhen Sie die Cache-Größe von client und proxy_temp um 1 GB für jedes neue Finesse-Cluster, das der Konfiguration hinzugefügt wird.

2. Mounten Sie die neuen Mount-Punkte mit dem Befehl mount -av.
3. Überprüfen Sie, ob das Dateisystem die neuen Einhängepunkte mit dem df -h Befehl eingehängt hat.
4. Ändern Sie die proxy_cache_path-Speicherorte in den Finesse- und CUIC-Cache-Konfigurationsdateien.

   Um beispielsweise die Pfade für das primäre Finesse zu ändern, gehen Sie zu <nginx-install-directory>conf/conf.d/finesse/caches und ändern Sie den vorhandenen Cache-Speicherort /usr/local/openresty/nginx/cache/finesse25/ zum neu erstellten Dateisystem-Speicherort. /home/primaryFinesse
   
   ##Must-change /usr/local/openresty/nginx/cache/finesse25 location would change depending on folder extraction proxy_cache_path /home/primaryFinesse/desktop levels=1:2 use_temp_path=on keys_zone=desktop_cache_fin25:10m max_size=15m inactive=3y use_temp_path=off; proxy_cache_path /home/primaryFinesse/shindig levels=1:2 use_temp_path=on keys_zone=shindig_cache_fin25:10m max_size=500m inactive=3y use_temp_path=off; proxy_cache_path /home/primaryFinesse/openfire levels=1:2 use_temp_path=on keys_zone=openfire_cache_fin25:10m max_size=10m inactive=3y use_temp_path=off; proxy_cache_path /home/primaryFinesse/rest levels=1:2 use_temp_path=on keys_zone=rest_cache_fin25:10m max_size=1500m inactive=40m use_temp_path=off;
   
   

5. Führen Sie für die sekundären Finesse- und CUIC-Server die gleichen Schritte aus.

Hinweis: Stellen Sie sicher, dass die Summe aller tmpfs-Laufwerksgrößen, die in den vorherigen Schritten erstellt wurden, zur endgültigen Speichergröße für die Bereitstellung hinzugefügt wird, da diese Laufwerke Speicherblöcke sind, die so konfiguriert sind, dass sie für die Anwendung wie Datenträger aussehen und so viel Speicherplatz belegen.

SSL-Zertifikate konfigurieren

Selbstsignierte Zertifikate verwenden - Testbereitstellungen

Selbstsignierte Zertifikate sollten nur verwendet werden, bis der Reverse Proxy einsatzbereit ist. Verwenden Sie in einer Produktionsbereitstellung nur ein von der Zertifizierungsstelle (Certificate Authority, CA) signiertes Zertifikat.

1. Generieren Sie Nginx-Zertifikate für SSL-Ordnerinhalt. Bevor Sie Zertifikate generieren, müssen Sie einen Ordner namens ssl unter /usr/local/openresty/nginx erstellen. Mithilfe dieser Befehle müssen Sie zwei Zertifikate generieren (eines für <reverseproxy_primary_fqdn> und eines für <reverseproxy_secondary_fqdn>).
   1. sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /usr/local/openresty/nginx/ssl/nginx.key -out /usr/local/openresty/nginx/ssl/nginx.crt (Hostname übergeben an : <reverseproxy_primary_fqdn>)
   2. sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /usr/local/openresty/nginx/ssl/nginxnode2.key -out /usr/local/openresty/nginx/ssl/nginxnode2.crt (Hostname übergeben als :<reverseproxy_second_fqdn>)
   3. Stellen Sie sicher, dass der Zertifikatpfad /usr/local/openresty/nginx/ssl/nginx.crt und /usr/local/openresty/nginx/ssl/nginxnode2.crt lautet, da diese bereits in den Finesse Nginx-Konfigurationsdateien konfiguriert sind.
2. Ändern Sie die Berechtigung des privaten Schlüssels 400 (r--------).
3. Konfigurieren Sie die Firewall/iptables auf dem Reverse Proxy so, dass die Kommunikation von der Firewall den Ports entspricht, für die der Nginx-Server konfiguriert wurde.
4. Fügen Sie die IP-Adresse und den Hostnamen von Finesse, IdS und CUIC unter dem Eintrag /etc/hosts auf dem Reverse Proxy-Server hinzu.
5. Weitere Informationen zur Konfiguration des Nginx-Hosts als Reverse Proxy finden Sie im Leitfaden zu den Funktionen der Lösung für die auf den Komponentenservern auszuführenden Konfigurationen.

Hinweis: Die bereitgestellte Konfiguration ist für eine Beispielbereitstellung im Jahr 2000 und muss für eine größere Bereitstellung entsprechend erweitert werden.

Signiertes Zertifikat der Zertifizierungsstelle verwenden - Produktionsbereitstellungen

Ein CA-signiertes Zertifikat kann auf dem Reverse Proxy mit folgenden Schritten installiert werden:

1. Generieren Sie die Zertifikatsanforderung (Certificate Signing Request, CSR).

   Um die CSR-Anfrage und den privaten Schlüssel zu generieren, gebenopenssl req -new -newkey rsa:4096 -keyout nginx.key -out nginx.csrSie nach der Anmeldung beim Proxy ein. Folgen Sie der Eingabeaufforderung, und geben Sie die Details an. Dadurch werden der CSR (im Beispiel nginx.csr) und der private RSA-Schlüssel (im Beispiel nginx.key) mit 4096 Bit Stärke generiert.

   Beispiele:
   
   [root@reverseproxyhost.companyname.com ssl]# openssl req -new -newkey rsa:4096 -keyout nginx.key -out nginx.csr Generating a RSA private key .....+++++ ...................................................................................................................................................+++++ writing new private key to 'nginx.key' Enter PEM pass phrase:passphrase Verifying - Enter PEM pass phrase:passphrase ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:CA Locality Name (eg, city) [Default City]:Orange County Organization Name (eg, company) [Default Company Ltd]:CompanyName Organizational Unit Name (eg, section) []:BusinessUnit Common Name (eg, your name or your server's hostname) []:reverseproxyhostname.companydomain.com Email Address []:john.doe@comapnydomain.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:challengePWD An optional company name []:CompanyName
   
   Notieren Sie sich die PEM-Passphrase, da diese zum Entschlüsseln des privaten Schlüssels während der Bereitstellung verwendet wird.
   
   

2. Abrufen des signierten Zertifikats von der Zertifizierungsstelle

   Senden Sie die CSR-Anfrage an die Zertifizierungsstelle, und holen Sie das signierte Zertifikat ein.

   Hinweis: Wenn das von der Zertifizierungsstelle empfangene Zertifikat keine Zertifikatskette ist, die alle entsprechenden Zertifikate enthält, fassen Sie alle relevanten Zertifikate in einer einzigen Zertifikatskettendatei zusammen.

3. Stellen Sie das Zertifikat und den Schlüssel bereit.

   Entschlüsseln Sie den zuvor generierten Schlüssel im ersten Schritt mitopenssl rsa -in nginx.key -out nginx_decrypted.keydem Befehl. Platzieren Sie das CA-signierte Zertifikat und den entschlüsselten Schlüssel im Ordner /usr/local/openresty/nginx/ssl auf dem Reverse-Proxy-Rechner. Aktualisieren Sie SSL-Konfigurationen für das Zertifikat, bzw. fügen Sie sie in den Nginx-Konfigurationen der Konfigurationsdatei /usr/local/openresty/nginx/conf/conf.d/ssl/ssl.conf hinzu. 

   
   ssl_certificate /usr/local/openresty/nginx/ssl/ca_signed_cert.crt; ssl_certificate_key /usr/local/openresty/nginx/ssl/nginx_decrypted.key;

4. Konfigurieren Sie die Berechtigungen für die Zertifikate.

   chmod 400 /usr/local/openresty/nginx/ssl/ca_signed_cert.crtEingebenchmod 400 /usr/local/openresty/nginx/ssl/nginx_decrypted.key, sodass das Zertifikat schreibgeschützt ist und auf den Besitzer beschränkt ist.

5. Nginx neu laden.
   
   

   Benutzerdefinierten Diffie-Hellman-Parameter verwenden

   Erstellen Sie einen benutzerdefinierten Diffie-Hellman-Parameter mit den folgenden Befehlen:
   
   openssl dhparam -out /usr/local/openresty/nginx/ssl/dhparam.pem 2048 chmod 400 /usr/local/openresty/nginx/ssl/dhparam.pem
   
   
   Ändern Sie die Serverkonfiguration, um die neuen Parameter in der Datei /usr/local/openresty/nginx/conf/conf.d/ssl/ssl.conf:
   
   ssl_dhparam /usr/local/openresty/nginx/ssl/dhparam.pem;

Stellen Sie sicher, dass das OCSP-Heften aktiviert ist - Überprüfung auf Zertifikatsperrung

Hinweis: Um dies zu aktivieren, sollte der Server ein CA-signiertes Zertifikat verwenden und der Server sollte Zugriff auf die CA haben, die das Zertifikat signiert hat.

Fügen Sie diese Konfiguration im Verzeichnis file/usr/local/openresty/nginx/conf/conf.d/ssl/ssl.conf:

ssl_stapling on; ssl_stapling_verify on;

Nginx-Konfiguration

Die Standard-Nginx-Konfigurationsdatei (/usr/local/openresty/nginx/conf/nginx.conf) muss geändert werden, um diese Einträge zu enthalten, um Sicherheit und Leistung durchzusetzen. Dieser Inhalt sollte verwendet werden, um die Standardkonfigurationsdatei zu ändern, die von der Nginx-Installation erstellt wird.

# Increasing number of worker processes will not increase the processing the request. The number of worker process will be same as number of cores
# in system CPU. Nginx provides "auto" option to automate this, which will spawn one worker for each CPU core.
worker_processes  auto;

# Process id file location
pid /usr/local/openresty/nginx/logs/nginx.pid;

# Binds each worker process to a separate CPU
worker_cpu_affinity auto;

#Defines the scheduling priority for worker processes. This should be calculated by "nice" command. In our proxy set up the value is 0
worker_priority 0;


error_log  /usr/local/openresty/nginx/logs/error.log info;

#user root root;

# current limit on the maximum number of open files by worker processes, keeping 10 times of worker_connections

worker_rlimit_nofile 102400;

events {
    multi_accept on;


    # Sets the maximum number of simultaneous connections that can be opened by a worker process.
    # This should not be more the current limit on the maximum number of open files i.e. hard limit of the maximum number of open files for the user (ulimit -Hn)
    # The appropriate setting depends on the size of the server and the nature of the traffic, and can be discovered through testing.
    worker_connections  10240;
    #debug_connection 10.78.95.21
}


http {

    include       mime.types;


    default_type  text/plain;


    ## Must-change Change with DNS resolver ip in deployment
    resolver 192.168.1.3;


    ## Must-change change lua package path to load lua libraries
    lua_package_path  "/usr/local/openresty/lualib/resty/?.lua;/usr/local/openresty/nginx/lua/?.lua;;"


    ## Must-change change proxy_temp folder as per cache directory configurations
    proxy_temp_path /usr/local/openresty/nginx/cache/proxy_temp 1 2 ;
    ## Must-change change client_temp folder as per cache directory configurations
    client_body_temp_path /usr/local/openresty/nginx/cache/client_temp 1 2 ;


    lua_shared_dict userlist 50m;
    lua_shared_dict credentialsstore 100m;
    lua_shared_dict userscount 100k;
    lua_shared_dict clientstorage 100m;
    lua_shared_dict blockingresources 100m;
    lua_shared_dict tokencache_saproxy 10M;
    lua_shared_dict tokencache_saproxy125 10M;
    lua_shared_dict ipstore 10m;
    lua_shared_dict desktopurllist 10m;
    lua_shared_dict desktopurlcount 100k;
    lua_shared_dict thirdpartygadgeturllist 10m;
    lua_shared_dict thirdpartygadgeturlcount 100k;
    lua_shared_dict corsheadersstore 100k;


    init_worker_by_lua_block {
        local UsersListManager = require('users_list_manager')
        local UnauthenticatedDesktopResourcesManager = require("unauthenticated_desktopresources_manager")
        local UnauthenticatedResourcesManager = require("unauthenticated_thirdpartyresources_manager")
        --  Must-change Replace saproxy.cisco.com with reverseproxy fqdn

        if  ngx.worker.id() == 0 then
            UsersListManager.getUserList("saproxy.cisco.com", "https://saproxy.cisco.com:8445/finesse/api/Users")
            UnauthenticatedDesktopResourcesManager.getDesktopResources("saproxy.cisco.com", "https://saproxy.cisco.com:8445/desktop/api/urls?type=desktop") 
            UnauthenticatedResourcesManager.getThirdPartyGadgetResources("saproxy.cisco.com", "https://saproxy.cisco.com:8445/desktop/api/urls?type=3rdParty")
        end 
    }

    include conf.d/*.conf;

    sendfile        on;

    tcp_nopush     on;

    server_names_hash_bucket_size 512;

Reverse Proxy-Port konfigurieren

Standardmäßig wartet die Nginx-Konfiguration auf Port 8445 auf Finesse-Anfragen. Von einem Reverse Proxy kann jeweils nur ein Port aktiviert werden, um Finesse-Anfragen zu unterstützen, z. B. 8445. Wenn Port 443 unterstützt werden muss, bearbeiten Sie die Datei <nginx-install-directory>conf/conf.d/finesse.conf, um Listening auf 443 zu aktivieren und Listening auf 8445 zu deaktivieren.

Konfigurieren der gegenseitigen TLS-Authentifizierung zwischen Reverse Proxy- und Upstream-Komponenten

Die Client-SSL-Zertifikatsauthentifizierung für Verbindungen von Reverse-Proxy-Hosts kann für die vorgelagerten CCBU-Komponenten CUIC/Finesse/IdS/Livedata mithilfe der neuen CVOS CLI-Option aktiviert werden, die lautet:

utils system reverse-proxy client-auth enable/disable/status.

Standardmäßig ist diese Option deaktiviert und muss vom Administrator explizit aktiviert werden, indem CLI auf jedem Upstream-Server separat ausgeführt wird. Wenn diese Option aktiviert ist, beginnt der auf dem Upstream-Host ausgeführte Cisco Web-Proxy-Dienst mit der Authentifizierung von Client-Zertifikaten im TLS-Handshake für Verbindungen, die von vertrauenswürdigen Reverse Proxy-Hosts stammen, die als Teil von CLI utils system reverse-proxy allowed-hosts add <proxy-host> hinzugefügt wurden.

Unten sehen Sie den Konfigurationsblock für dasselbe Verzeichnis in den Proxykonfigurationsdateien ssl.conf und ssl2.conf.

#Must-change /usr/local/openresty/nginx/ssl/nginx.crt change this location accordingly proxy_ssl_certificate /usr/local/openresty/nginx/ssl/nginx.crt; #Must-change /usr/local/openresty/nginx/ssl/nginx.key change this location accordingly proxy_ssl_certificate_key /usr/local/openresty/nginx/ssl/nginx.key;

Das SSL-Zertifikat, das für ausgehenden Datenverkehr (Proxy an Upstream) verwendet wird, kann mit dem SSL-Zertifikat übereinstimmen, das für eingehenden Datenverkehr konfiguriert wurde (SSL-Connector für Komponenten-Serverblöcke). Wenn ein selbstsigniertes Zertifikat als proxy_ssl_certificate verwendet wird, muss es an Upstream-Komponenten (Finesse/IdS/CUIC/Livedata) hochgeladen werden, damit es erfolgreich authentifiziert werden kann.

Die Validierung von Upstream-Serverzertifikaten durch Reverse Proxy ist optional und standardmäßig deaktiviert. Wenn Sie eine vollständige gegenseitige TLS-Authentifizierung zwischen Reverse Proxy und Upstream-Hosts erreichen möchten, muss die unten gezeigte Konfiguration aus den Dateien ssl.conf und ssl2.conf entfernt werden.

#Enforce upstream server certificate validation at proxy -> #this is not mandated as per CIS buit definitely adds to security. #It requires the administrator to upload all upstream server certificates to the proxy certificate store #Must-Change Uncomment below lines IF need to enforce upstream server certificate validation at proxy #proxy_ssl_verify on; #proxy_ssl_trusted_certificate /usr/local/openresty/nginx/ssl/finesse25.crt; proxy_ssl_trusted_certificate: This file should contain the all upstream certificate enteries concatenated together

Einschränkungen für die Konfiguration gegenseitiger TLS-Authentifizierung:

• Wenn diese Funktion für CCBU-Komponenten aktiviert ist, werden Client-Zertifikate von LAN-Clients auch während des TLS-Handshakes angefragt. Falls Client-/persönliche Zertifikate auf dem Client-Computer installiert sind, können Browser ein Popup-Fenster für den Endbenutzer auswählen, in dem dieser aufgefordert wird, das entsprechende Zertifikat für die Client-Authentifizierung auszuwählen. Es spielt zwar keine Rolle, welches Zertifikat der Endbenutzer auswählt oder auf "Abbrechen" drückt, die Popup-Anfragen werden jedoch erfolgreich sein, da die Client-Zertifikatauthentifizierung für LAN-Clients nicht erzwungen wird. Die Benutzererfahrung ändert sich jedoch. Siehe CDET CSCwa26057 für weitere Informationen.
• Der Webproxy-Dienst der Upstream-Komponenten wird nicht angezeigt, wenn ein Proxyhost zur Zulassungsliste hinzugefügt wird, die vom Webproxy-Dienst nicht aufgelöst werden kann. Stellen Sie sicher, dass Reverse-Proxy-Hosts, die der Zulassungsliste hinzugefügt wurden, über die DNS-Suche von der Upstream-Komponente aufgelöst werden können.
  
  

Cache leeren

Der Reverse-Proxy-Cache kann mit dem /clearCache.sh Befehl gelöscht werden.

Standardrichtlinien

Dieser Abschnitt beschreibt kurz die Standardrichtlinien, die eingehalten werden müssen, wenn Sie Nginx als Proxy-Server einrichten.

Diese Richtlinien wurden vom Center for Internet Security abgeleitet. Weitere Informationen zu den einzelnen Richtlinien finden Sie im gleichen Dokument.

1. Es wird immer empfohlen, die neueste stabile OpenResty- und OpenSSL-Version zu verwenden.
2. Es wird empfohlen, Nginx in einem separaten Laufwerk-Mount zu installieren.
3. Die Nginx-Prozess-ID muss dem Root-Benutzer gehören (oder, falls für das ausgewählte Betriebssystem zutreffend) und über die Berechtigung 644 (rw-------) oder eine striktere Berechtigung verfügen.
4. Nginx muss Anforderungen für unbekannte Hosts blockieren. Stellen Sie sicher, dass jeder Serverblock die Server_Name-Direktive explizit enthält. Um zu überprüfen, durchsuchen Sie alle Serverblöcke im Verzeichnis nginx.conf und nginx/conf.d und vergewissern Sie sich, dass alle Serverblöcke den Servernamen enthalten.
5. Nginx darf nur auf autorisierte Ports lauschen. Durchsuchen Sie alle Serverblöcke im Verzeichnis nginx.conf und nginx/conf.d, und überprüfen Sie, ob Listen-to-Listen-Direktiven vorhanden sind, um sicherzustellen, dass nur die autorisierten Ports für Listening geöffnet sind.
6. Da Cisco Finesse HTTP nicht unterstützt, wird empfohlen, auch den HTTP-Port des Proxyservers zu blockieren.
7. Beim Nginx-SSL-Protokoll muss es sich um TLS 1.2 handeln. Die Unterstützung für ältere SSL-Protokolle muss entfernt werden. Außerdem müssen schwache SSL-Verschlüsselungen deaktiviert werden.
8. Es wird empfohlen, Nginx-Fehler- und Zugriffsprotokolle an den Remote-Syslog-Server zu senden.
9. Es wird empfohlen, das Modul mod_security zu installieren, das als Webanwendungs-Firewall funktioniert. Weitere Informationen finden Sie im ModSecurity-Handbuch. Beachten Sie, dass die Nginx-Last nicht innerhalb des vorhandenen mod_security-Moduls überprüft wurde.

Konfigurieren der Zuordnungsdatei

Für die Reverse-Proxy-Bereitstellung des Finesse-Desktops ist eine Zuordnungsdatei erforderlich, um die Liste der von außen sichtbaren Hostnamen/Port-Kombinationen und deren Zuordnung zu den tatsächlichen Servernamen und Ports zu konfigurieren, die von den Finesse-, IdS- und CUIC-Servern verwendet werden. Diese Zuordnungsdatei, die auf internen Servern konfiguriert wird, ist die Schlüsselkonfiguration, mit der die über das Internet verbundenen Clients zu den erforderlichen Hosts und Ports umgeleitet werden können, die im Internet verwendet werden.

Die Zuordnungsdatei muss auf einem Webserver bereitgestellt werden, auf den die Komponentenserver zugreifen können, und ihr URI muss konfiguriert werden, damit die Bereitstellung funktioniert. Es wird empfohlen, die Zuordnungsdatei mit einem dedizierten Webserver zu konfigurieren, der im Netzwerk verfügbar ist. Steht ein solcher Server nicht zur Verfügung, kann stattdessen der Reverse Proxy verwendet werden. Dies setzt voraus, dass der Proxy innerhalb des Netzwerks zugänglich ist, und birgt außerdem das Risiko, dass die Informationen externen Clients zugänglich gemacht werden, die unbefugten Zugriff auf die DMZ haben können. Im nächsten Abschnitt wird beschrieben, wie dies erreicht werden kann.

Im Funktionshandbuch finden Sie die genauen Schritte zum Konfigurieren des Zuordnungsdatei-URI auf allen Komponentenservern sowie weitere Informationen zum Erstellen der Zuordnungsdateidaten.

Reverse Proxy als Zuordnungsdateiserver verwenden

Diese Schritte sind nur erforderlich, wenn der Reverse Proxy auch als Host für die Proxy-Zuordnungsdatei verwendet wird.

1. Konfigurieren Sie den Reverse-Proxy-Hostnamen im von den Finesse/CUIC- und IdS-Hosts verwendeten Domänencontroller so, dass dessen IP-Adresse aufgelöst werden kann.
2. Laden Sie die generierten signierten Nginx-Zertifikate auf beide Knoten unter tomcat-trust von cmplatform hoch und starten Sie den Server neu.
3. Aktualisieren Sie die Werte für die erforderliche Änderung in <NGINX_HOME>/html/proxymap.txt.
4. Laden Sie Nginx-Konfigurationen mit dem nginx -s reload Befehl neu.
5. Überprüfen Sie, ob mithilfe des Befehls von einem anderen Netzwerk-Host aus auf die Konfigurationsdatei zugegriffen werden curl kann.

CentOS 8 Kernel-Sicherung

Wenn das gewählte Betriebssystem CentOS 8 ist, wird empfohlen, die Kernel-Härtung/-Optimierung mit diesen sysctl-Konfigurationen für Installationen durchzuführen, die einen dedizierten Server zum Hosten des Proxys verwenden.

## Configurations for kernel hardening - CentOS8. The file path is /etc/sysctl.conf
## Note that the commented configurations denote that CentOS 8's default value matches
## the recommended/tested value, and are not security related configurations.

# Avoid a smurf attack
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Turn on protection for bad icmp error messages
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Turn on syncookies for SYN flood attack protection
net.ipv4.tcp_syncookies = 1

# Turn on and log spoofed, source routed, and redirect packets
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# Turn off routing
net.ipv4.ip_forward = 0
net.ipv4.conf.all.forwarding = 0
net.ipv6.conf.all.forwarding = 0

net.ipv4.conf.all.mc_forwarding = 0
net.ipv6.conf.all.mc_forwarding = 0

# Block routed packets
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Block ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Filter routing packets with inward-outward path mismatch(reverse path filtering)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Router solicitations & advertisements related.
net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.default.max_addresses = 1
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0

# Backlog - increased from default 1000 to 5000.
net.core.netdev_max_backlog = 5000

# Setting syn/syn-ack retries to zero, so that they don't stay in the queue.
net.ipv4.tcp_syn_retries = 0
net.ipv4.tcp_synack_retries = 0

# Max tcp listen backlog. Setting it to 511 to match nginx config
net.core.somaxconn = 511

# Reduce the duration of connections held in TIME_WAIT(seconds)
net.ipv4.tcp_fin_timeout = 6

# Maximum resources allotted
# fs.file-max = 2019273
# kernel.pid_max = 4194304
# net.ipv4.ip_local_port_range = 32768 60999

# TCP window size tuning
# net.ipv4.tcp_window_scaling = 1
# net.core.rmem_default = 212992
# net.core.rmem_max = 212992
# net.ipv4.tcp_rmem = 4096 87380 6291456
# net.ipv4.udp_rmem_min = 4096
# net.core.wmem_default = 212992
# net.core.wmem_max = 212992
# net.ipv4.tcp_wmem = 4096 16384 4194304
# net.ipv4.udp_wmem_min = 4096
# vm.lowmem_reserve_ratio = 256 256 32 0 0
# net.ipv4.tcp_mem = 236373 315167 472746

# Randomize virtual address space
kernel.randomize_va_space = 2

# Congestion control
# net.core.default_qdisc = fq_codel
# net.ipv4.tcp_congestion_control = cubic

# Disable SysReq
kernel.sysrq = 0

# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536

# Controls the default maximum size of a message queue
kernel.msgmax = 65536

# Controls the eagerness of the kernel to swap.
vm.swappiness = 1

Ein Neustart wird empfohlen, nachdem Sie die empfohlenen Änderungen vorgenommen haben.

IP-Tabellen sichern

IPtables ist eine Anwendung, mit der ein Systemadministrator die IPv4- und IPv6-Tabellen, -Ketten und -Regeln konfigurieren kann, die von der Linux-Kernel-Firewall bereitgestellt werden.

Diese IP-Tabellen-Regeln sind so konfiguriert, dass sie die Proxy-Anwendung vor Brute-Force-Angriffen schützen, indem sie den Zugriff in der Linux-Kernel-Firewall einschränken.

Die Kommentare in der Konfiguration zeigen an, für welchen Service eine Durchsatzratenbeschränkung gemäß den Regeln erfolgt.

Hinweis: Wenn Administratoren einen anderen Port verwenden oder den Zugriff auf mehrere Server erweitern, die dieselben Ports verwenden, muss die entsprechende Dimensionierung für diese Ports basierend auf diesen Nummern vorgenommen werden.

## Configuration for iptables service
## The file path is /etc/sysconfig/iptables
## Make a note for must-change values to be replaced.
## Restart of the iptable service is required after applying following rules

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# Ensure loopback traffic is configured
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -s 127.0.0.0/8 -j DROP

# Ensure ping openeded only for the particular source and blocked for rest
# Must-Change: Replace the x.x.x.x with valid ip address
-A INPUT -p ICMP --icmp-type 8 -s x.x.x.x -j ACCEPT

# Ensure outbound and established connections are configured
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Block ssh for external interface
# Must-Change: Replace the ens224 with valid ethernet interface
-A INPUT -p tcp -i ens224 --dport 22 -j DROP
# Open inbound ssh(tcp port 22) connections
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT


# Configuration for finesse 8445 port
-A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Connections to 8445 exceeded connlimit "
-A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -j DROP
 -A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 6/sec --hashlimit-burst 8 --hashlimit-mode srcip,dstport --hashlimit-name TCP_8445_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 8445 hashlimit "
-A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -j DROP

# Configuration for IdS 8553 port
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IdS connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 2/sec --hashlimit-burst 4 --hashlimit-mode srcip,dstport --hashlimit-name TCP_8553_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 8553 hashlimit "
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -j DROP

# Configuration for IdP 443 port
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -m connlimit --connlimit-above 8 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IdP connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -m connlimit --connlimit-above 8 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 4/sec --hashlimit-burst 6 --hashlimit-mode srcip,dstport --hashlimit-name TCP_443_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 443 hashlimit "
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -j DROP


# Must-Change: A2A file transfer has not been considered for below IMNP configuration. 
# For A2A for support, these configuration must be recalculated to cater different file transfer scenarios.

# Configuration for IMNP 5280 port
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IMNP connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 20/sec --hashlimit-burst 25 --hashlimit-mode srcip,dstport --hashlimit-name TCP_5280_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 5280 hashlimit "
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -j DROP

# Configuration for IMNP 15280 port
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IMNP connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 20/sec --hashlimit-burst 25 --hashlimit-mode srcip,dstport --hashlimit-name TCP_15280_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 15280 hashlimit "
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -j DROP


# Configuration for IMNP 25280 port
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IMNP connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 20/sec --hashlimit-burst 25 --hashlimit-mode srcip,dstport --hashlimit-name TCP_25280_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 25280 hashlimit "
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -j DROP


# Configuration for CUIC 8444 port
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " CUIC connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 2/sec --hashlimit-burst 4 --hashlimit-mode srcip,dstport --hashlimit-name TCP_8444_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 8444 hashlimit "
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -j DROP

# Configuration for CUIC 8447 port
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " CUIC connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 2/sec --hashlimit-burst 4 --hashlimit-mode srcip,dstport --hashlimit-name  TCP_8447_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 8447 hashlimit "
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -j DROP

# Configuration for LiveData 12005  port
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " LD connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 6/sec --hashlimit-burst 8 --hashlimit-mode srcip,dstport --hashlimit-name TCP_12005_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 12005 hashlimit "
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -j DROP

# Configuration for LiveData 12008  port
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " LD connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 6/sec --hashlimit-burst 8 --hashlimit-mode srcip,dstport --hashlimit-name  TCP_12008_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 12008 hashlimit "
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -j DROP

# Block all other ports
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

COMMIT

Diese Regeln können direkt angewendet werden, indem Sie /etc/sysconfig/iptables manuell bearbeiten oder alternativ die Konfiguration in einer Datei wie iptables.conf speichern und cat iptables.conf >>/etc/sysconfig/iptables ausführen, um die Regeln anzuwenden.

Ein Neustart des IPtables-Dienstes ist erforderlich, nachdem Sie die Regeln angewendet haben. Geben Sie ein, systemctl restart iptables um den IPtables-Dienst neu zu starten.

Clientverbindungen einschränken

Zusätzlich zur vorherigen Konfiguration der IP-Tabellen wird empfohlen, dass Installationen, die den Adressbereich für Clients kennen, die den Proxy verwenden, dieses Wissen zum Schutz der Proxy-Zugriffsregeln verwenden. Dies kann enorme Vorteile mit sich bringen, wenn es darum geht, den Proxy vor Botnets bösartiger Netzwerke zu schützen, die häufig im IP-Adressbereich von Ländern erstellt werden, die laxere Regeln in Bezug auf die Online-Sicherheit haben. Es wird daher dringend empfohlen, die IP-Adressbereiche auf Länder-/bzw. ISP-basierte IP-Bereiche zu beschränken, wenn Sie sich der Zugriffsmuster sicher sind.

Blockieren von Client-Verbindungen

Es ist auch nützlich zu wissen, wie ein bestimmter Adressbereich blockiert wird, wenn ein Angriff anhand einer IP-Adresse oder eines IP-Adressbereichs erkannt wird. In solchen Fällen können die Anfragen von diesen IP-Adressen mit iptable Regeln blockiert werden.

Unterschiedliche IP-Adressen blockieren

Um mehrere eindeutige IP-Adressen zu blockieren, fügen Sie der IPTables-Konfigurationsdatei für jede IP-Adresse eine Zeile hinzu.

Um beispielsweise die Adressen 192.0.2.3 und 192.0.2.4 zu blockieren, geben Sie Folgendes ein:

iptables -A INPUT -s 192.0.2.3 -j DROP iptables -A INPUT -s 192.0.2.4 - j DROP.

Sperren eines Bereichs von IP-Adressen

Blockieren Sie mehrere IP-Adressen in einem Bereich, und fügen Sie der IPTables-Konfigurationsdatei mit dem IP-Bereich eine einzelne Zeile hinzu.

Um beispielsweise Adressen von 192.0.2.3 bis 192.0.2.35 zu blockieren, geben Sie Folgendes ein:

iptables -A INPUT -m iprange --src-range 192.0.2.3-192.0.2.35 -j DROP.

Alle IP-Adressen in einem Subnetz blockieren

Blockieren Sie alle IP-Adressen in einem gesamten Subnetz, indem Sie der IPTables-Konfigurationsdatei eine einzelne Zeile hinzufügen, und verwenden Sie dabei die klassenlose Routing-Schreibweise zwischen den Domänen für den IP-Adressbereich. Um beispielsweise alle Adressen der Klasse C zu blockieren, geben Sie Folgendes ein:

iptables -A INPUT -s 192.0.0.0/16 -j DROP.

SELinux

SELinux ist ein Plattform-Sicherheits-Framework, das als Erweiterung in das Linux-Betriebssystem integriert ist. Das Verfahren zum Installieren und Hinzufügen von SELinux-Richtlinien zum Ausführen von OpenResty als Reverse Proxy wird als Nächstes bereitgestellt.

1. Beenden Sie den Vorgang mit dem openresty -s stop Befehl.
2. Konfigurieren und starten Sie den /stop nginx-Server mit dem systemctl Befehl, sodass der OpenResty-Prozess während des Bootvorgangs automatisch gestartet wird. Geben Sie diese Befehle als root ein.
   1. Gehen Sie zu /usr/lib/systemd/system.
   2. Öffnen Sie die Datei openresty.service.
   3. Aktualisieren Sie den Inhalt der Datei entsprechend dem Speicherort der PIDFilei.

      [Unit]
      Description=The OpenResty Application Platform
      After=syslog.target network-online.target remote-fs.target nss-lookup.target
      Wants=network-online.target
       
      [Service]
      Type=forking
      PIDFile=/usr/local/openresty/nginx/logs/nginx.pid
      ExecStartPre=/usr/local/openresty/nginx/sbin/nginx -t
      ExecStart=/usr/local/openresty/nginx/sbin/nginx
      ExecReload=/bin/kill -s HUP $MAINPID
      ExecStop=/bin/kill -s QUIT $MAINPID
      PrivateTmp=true
       
      [Install]
      WantedBy=multi-user.target

   4. Geben Sie als Root-Benutzer sudo systemctl enable openrestyein.
   5. Starten / Stoppen Sie den OpenResty-Dienst mit dem systemctl start openresty / systemctl stop openresty Befehl und stellen Sie sicher, dass der Prozess als Root-Benutzer startet / stoppt.

1. Selinux installieren
   • Standardmäßig werden nur einige SELinux-Pakete in CentOs installiert.

   • Das Paket policycoreutils-devel und seine Abhängigkeiten müssen installiert werden, um die SELinux-Richtlinie zu generieren.

   • Geben Sie diesen Befehl ein, um policycoreutils-devel zu installieren.

     yum install policycoreutils-devel

   • Stellen Sie sicher, dass nach der Installation des Pakets der sepolicy Befehl funktioniert.

     usage: sepolicy [-h] [-P POLICY]
                       
                     {booleans,communicate,generate,gui,interface,manpage,network,transition}
                     ...
       
     SELinux Policy Inspection Tool

2. Neuen Linux-Benutzer erstellen und mit SElinux-Benutzer zuordnen

   1. Geben Sie ein, semanage login -l um die Zuordnung zwischen Linux-Benutzern und SELinux-Benutzern anzuzeigen.

      [root@loadproxy-cisco-com ~]# semanage login -l
        
      Login Name           SELinux User         MLS/MCS Range        Service
        
      __default__          unconfined_u         s0-s0:c0.c1023       *               *
      root                 unconfined_u         s0-s0:c0.c1023       *

   2. Erstellen Sie als root einen neuen Linux-Benutzer (nginx user), der dem SELinux user_u-Benutzer zugeordnet ist.

      useradd -Z user_u nginxuser
      [root@loadproxy-cisco-com ~]# passwd nginxuser
      Changing password for user nginxuser.
      New password:
      Retype new password:
      passwd: all authentication tokens updated successfully.

   3. Um die Zuordnung zwischen nginxuser und user_u anzuzeigen, geben Sie den folgenden Befehl als root ein:

      [root@loadproxy-cisco-com ~]# semanage login -l
        
      Login Name           SELinux User         MLS/MCS Range        Service
        
      __default__          unconfined_u         s0-s0:c0.c1023       *
      nginxuser            user_u               s0                   *
      root                 unconfined_u         s0-s0:c0.c1023       *

   4. SELinux __default__ login ist standardmäßig dem SELinux unrestricted_u-Benutzer zugeordnet. Es ist erforderlich, user_u standardmäßig mit dem folgenden Befehl einzuschränken:

      semanage login -m -s user_u -r s0 __default__

      Um zu überprüfen, ob der Befehl ordnungsgemäß funktioniert, geben Sie semanage login -lein. Es sollte folgende Ausgabe erzeugen:

      

   5. Ändern Sie nginx.conf, und führen Sie die Eigentümeränderung für nginxuser durch.

      1. Geben Sie chown -R nginxuser:nginxuser * im Verzeichnis <Openresty-install-directory> ein.

      2. Ändern Sie die Datei nginx.conf so, dass sie nginxuser als Benutzer für ausgeführte Arbeitsprozesse einbezieht.

         ........
           
         user nginxuser nginxuser;
           
         ..........

Schreiben Sie die SELinux-Richtlinie für Nginx.

1. Anstatt eine neue benutzerdefinierte Standardrichtlinie für Nginx mit dem sepolicy generate --init /usr/bin/nginx Befehl zu generieren, sollten Sie mit einer vorhandenen Richtlinie beginnen.
2. Die Dateien nginx.fc (File Contexts-Datei) und nginx.te (Type Enforcement-Datei), die von der angegebenen URL heruntergeladen wurden, wurden so geändert, dass sie der Verwendung des Reverse-Proxys entsprechen.
3. Diese modifizierte Version kann als Referenz verwendet werden, da sie für den jeweiligen Anwendungsfall behoben wurde.
4. Laden Sie die Datei selinux-nginx-rhel-master-modified.tar von der Datei-Software-Download-Seite herunter.

   

5. Extrahieren Sie die TAR-Datei, und navigieren Sie zum Verzeichnis nginx darin.
6. Öffnen Sie die Datei .fc, und überprüfen Sie die erforderlichen Dateipfade von nginx installer, cache und pid file.
7. Kompilieren Sie die Konfiguration mit dem make Befehl .
8. Die Datei nginx.pp wird generiert.
9. Laden Sie die Richtlinie mit dem semodule Befehl.

   semodule -i nginx.pp

10. Wechseln Sie zu /root, und erstellen Sie eine leere Datei mit dem Namen touch /.autorelabel.
11. Starten Sie das System neu.
12. Geben Sie diesen Befehl ein, um zu überprüfen, ob die Richtlinie erfolgreich geladen wurde.

    semodule --list-modules=full

    

13. Nginx sollte ohne jede Verletzung laufen. (Verstöße sind in /var/log/messages und /var/log/audit/audit.log verfügbar).
14. Geben Sie diesen Befehl ein, um den Status von Nginx zu überprüfen.

    ps -aefZ | grep nginx

    

15. Nun sollte der Desktop des Finesse-Agenten/Supervisors zugänglich sein.

Überprüfung

Verwenden Sie diesen Abschnitt, um zu überprüfen, ob Ihre Konfiguration ordnungsgemäß funktioniert.

Finesse

1. Fordern Sie https://<reverseproxy:port>/finesse/api/SystemInfo. von der DMZ an, und prüfen Sie, ob diese erreichbar sind.
2. Check <host>-Werte sowohl in <primaryNode> als auch in <secondaryNode> sind gültige Reverse-Proxy-Hostnamen. Es sollten keine Finesse-Hostnamen sein.

CUIC und Live-Daten

1. Wenn Finesse-Hostnamen in der Antwort anstatt Reverse-Proxy-Hostnamen angezeigt werden, überprüfen Sie die Proxy-Zuordnungskonfigurationen, und zulässige Hosts werden in Finesse-Servern ordnungsgemäß hinzugefügt, wie im Abschnitt "Populate Network Translation Data" von "VPN-Less Access to Finesse Desktop" im Finesse 12.6 UCCE Feature Guide beschrieben.
2. Wenn LiveData-Gadgets in Finesse Desktop ordnungsgemäß geladen werden, sind die CUIC- und LiveData-Proxykonfigurationen korrekt.
3. Zur Validierung der CUIC- und LiveData-Konfiguration müssen HTTP-Anforderungen an diese URLs von der DMZ gesendet werden, um festzustellen, ob sie erreichbar sind.
   • https://<reverseproxy:cuic_port>/cuic/rest/about
   • https://<reverseproxy:ldweb_port>/livedata/security
   • https://<reverseproxy:ldsocketio_port>/security

IDS

Um die IDs-Konfiguration zu validieren, gehen Sie wie folgt vor:

1. Melden Sie sich bei der IdSAdmin-Schnittstelle unter https://<ids_LAN_host:ids_port>:8553/idsadmin vom LAN an, da die Admin-Schnittstelle nicht über den Reverse-Proxy verfügbar gemacht wird.
2. Wählen Sie Einstellungen > IDs Trust aus.
3. Überprüfen Sie, ob der Herausgeberknoten des Proxyclusters auf der Seite "SP-Metadaten herunterladen" aufgeführt ist, und klicken Sie auf "Weiter".
4. Überprüfen Sie, ob der IDP-Proxy korrekt angezeigt wird, wenn er auf der Seite "IDP-Metadaten hochladen" konfiguriert wurde, und klicken Sie auf Weiter.
5. Initiieren Sie Test-SSO über alle Proxy-Cluster-Knoten von der Seite Test-SSO, und stellen Sie sicher, dass alle erfolgreich sind. Dies erfordert die Verbindung mit dem Client-Computer, um die Proxyknoten rückgängig zu machen.

Leistung

Die mit dem nmon-Tool erstellte Datenanalyse der äquivalenten Spitzenleistungserfassung ist auf der Software-Download-Seite von Finesse Release 12.6(1) ES03 (load_result.zip) verfügbar. Die Daten stellen den Status des Proxys für Desktop- und Supervisor-Vorgänge in einer Beispielbereitstellung von 2.000 UCCE mit SSO-Anmeldungen und CUIC LD-Berichten dar, wie im Standardlayout für 2.000 Benutzer für einen Zeitraum von acht Stunden konfiguriert. Er kann verwendet werden, um die Computing-, Festplatten- und Netzwerkanforderungen für eine Installation abzuleiten, bei der Nginx auf vergleichbarer Hardware verwendet wird.

Fehlerbehebung

SSO

1. Desktop-Umleitungen, die nicht über den Proxy erfolgen
   1. Überprüfen Sie, ob die Hostnamen in den richtigen Fällen gemäß den tatsächlichen VM-Hostnamen in verschiedenen Konfigurationen wie proxymap.txt, server_filter file usw. konfiguriert sind.
   2. Stellen Sie sicher, dass IdS mit dem richtigen Hostnamen im CCE-Bestand hinzugefügt wird, da bei der Registrierung für SSO vom CCE-Webadministrator dieselben Informationen an die Komponenten weitergeleitet werden.
2. SSO-Anmeldungen sind nicht möglich.
   1. Stellen Sie sicher, dass die IdS-IDP-Vertrauensstellung für den Proxyhost eingerichtet ist.
      
      

SELinux

1. Wenn Nginx nicht standardmäßig gestartet wird oder der Finesse-Agent-Desktop nicht zugänglich ist, setzen Sie SELinux mit dem folgenden Befehl auf den permissiven Modus:

   setenforce 0

2. Versuchen Sie, den Nginx mit dem systemctl restart nginx Befehl neu zu starten.
3. Verstöße werden in /var/log/messages und /var/log/audit/audit.log verfügbar sein.
4. Es ist erforderlich, die .te-Datei mit Zulassungsregeln neu zu generieren, um diese Verstöße mit einem der folgenden Befehle zu beheben:

   cat /var/log/audit/audit.log | audit2allow -m nginx1 > nginx1.te. # this will create nginx1.te file
                   or
   ausearch -c 'nginx' --raw | audit2allow -M  my-nginx  # this will create my-nginx.te file

5. Aktualisieren Sie die ursprüngliche Datei nginx.te im Verzeichnis selinux-nginx-rhel-master-modified/nginx mit neu generierten Zulassungsregeln.
6. Kompilieren Sie dasselbe mit dem make Befehl.
7. Die Datei "nginx.pp" wird neu generiert.
8. Laden Sie die Richtlinie über den Befehl semodule.

   semodule -i nginx.pp

9. Machen Sie SELinux mit diesem Befehl zum Erzwingen des Modus:

   setenforce

10. Starten Sie das System neu.
11. Wiederholen Sie diesen Vorgang, bis die erforderlichen Verstöße behoben sind.