Häufig verwendete Anwendungsregeln.

HTTP/HTTPS-Umleitung nach Bedingung

Mit einem Anwendungsprofil können Sie eine HTTP/HTTPS-Umleitung angeben, die den Datenverkehr immer umleitet, unabhängig von den angeforderten URLs. Sie haben außerdem die Flexibilität, die Bedingungen anzugeben, unter denen der HTTP/HTTPS-Datenverkehr umgeleitet werden soll.
move the login URL only to HTTPS. 
acl clear dst_port 80
acl secure dst_port 8080
acl login_page url_beg /login 
acl logout url_beg /logout 
acl uid_given url_reg /login?userid=[^&]+ 
acl cookie_set hdr_sub(cookie) SEEN=1
redirect prefix https://mysite.com set-cookie SEEN=1 if !cookie_set
redirect prefix https://mysite.com if login_page !secure
redirect prefix http://mysite.com drop-query if login_page !uid_given
redirect location http://mysite.com/ if !login_page secure
 redirect location / clear-cookie USERID= if logout

Routing nach Domänenname

Sie können eine Anwendungsregel erstellen, mit der Anforderungen je nach dem Domänennamen an einen spezifischen Load-Balancer-Pool geleitet werden. Die folgende Regel leitet Anforderungen an foo.com an pool_1 und Anforderungen an bar.com an pool_2.
acl is_foo hdr_dom(host) -i foo
  acl is_bar hdr_dom(host) -i bar
  use_backend pool_1 if is_foo
  use_backend pool_2  if is_bar

Microsoft RDP-Load-Balancing und Schutz

In dem folgenden Beispielszenario verteilt der Load Balancer einen neuen Nutzer auf den weniger ausgelasteten Server und nimmt eine unterbrochene Sitzung wieder auf. Die IP-Adresse der internen NSX Edge-Schnittstelle für dieses Szenario lautet 10.0.0.18, die interne Schnittstellen-IP-Adresse lautet 192.168.1.1 und die virtuellen Server haben die Adressen 192.168.1.100, 192.168.1.101 und 192.168.1.102.
  1. Erstellen Sie ein Anwendungsprofil für den TCP-Verkehr mit MSRDP-Persistenz.
  2. Erstellen Sie eine TCP-Statusüberwachung (tcp_monitor).
  3. Erstellen Sie einen Pool (namens rdp-pool) mit den Mitgliedern 192.168.1.100:3389, 192.168.1.101:3389 und 192.168.1.102:3389.
  4. Ordnen Sie tcp_monitor to rdp-pool zu.
  5. Erstellen Sie die folgende Anwendungsregel.
    tcp-request content track-sc1 rdp_cookie(mstshash) table rdp-pool
    tcp-request content track-sc2 src table ipv4_ip_table
     
    #   each single IP can have up to 2 connections on the VDI infrastructure
    tcp-request content reject if { sc2_conn_cur ge 2 }
    
    #   each single IP can try up to 5 connections in a single minute
    tcp-request content reject if { sc2_conn_rate ge 10 }
    
    # Each user is supposed to get a single active connection at a time, block the second one
    tcp-request content reject if { sc1_conn_cur ge 2 }
    
    # if a user tried to get connected at least 10 times over the last minute, 
    # it could be a brute force
    tcp-request content reject if { sc1_conn_rate ge 10 }
    
    
  6. Erstellen Sie einen virtuellen Server (namens rdp-vs).
  7. Ordnen Sie das Anwendungsprofil diesem virtuellen Server zu und fügen Sie die in Schritt 4 erstellte Anwendungsregel hinzu.

Die neu zugewiesene Anwendungsregel auf dem virtuellen Server stellt einen Schutz für RDP-Server dar.

Erweiterte Protokollierung

Der NSX-Load-Balancer unterstützt standardmäßig die allgemeine Protokollierung. Sie können wie folgt eine Anwendungsregel erstellen, um detailliertere Protokollierungsmeldungen für die Fehlersuche und -behebung anzuzeigen.
 # log the name of the virtual server
 capture request  header Host len 32

 # log the amount of data uploaded during a POST
 capture request  header Content-Length len 10
# log the beginning of the referrer
capture request  header Referer len 20

# server name (useful for outgoing proxies only)
capture response header Server len 20

# logging the content-length is useful with "option logasap"
capture response header Content-Length len 10

# log the expected cache behaviour on the response
capture response header Cache-Control len 8

# the Via header will report the next proxy's name
 capture response header Via len 20

# log the URL location during a redirection
capture response header Location len 20
Nachdem Sie die Anwendungsregel dem virtuellen Server zugeordnet haben, enthalten die Protokolle detaillierte Meldungen, wie zum Beispiel die folgende.
2013-04-25T09:18:17+00:00 edge-187 loadbalancer[18498]: [org1]: 10.117.7.117 - - [25/Apr/2013:09:18:16 +0000] "GET /favicon.ico HTTP/1.1" 404 1440 "" "" 51656 856 "vip-http-complete" 
"pool-http-complete" "m2" 145 0 1 26 172 --NI 1 1 0 0 0 0 0 "" "" "10.117.35.187" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 
(KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31" "Apache/2.2.15 (Linux" ""

2013-04-25T09:18:17+00:00 edge-187 loadbalancer[18498]: [org1]: 10.117.7.117 - - [25/Apr/2013:09:18:16 +0000] "GET /favicon.ico HTTP/1.1" 404 1440 "" "" 51657 856 "vip-http-complete" 
"pool-http-complete" "m2" 412 0 0 2 414 --NI 0 0 0 0 0 0 0 "" "" "10.117.35.187" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 
(KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31" "Apache/2.2.15 (Linux" ""
Zur Fehlersuche und -behebung beim HTTPS-Datenverkehr müssen Sie möglicherweise weitere Regeln hinzufügen. Die meisten Webanwendungen verwenden 301/302-Antworten mit einem Adressheader, um den Client zu einer Seite umzuleiten (meistens nach einer Anmeldung oder einem POST-Aufruf) und erfordern außerdem ein Anwendungscookie. Ihr Anwendungsserver könnte daher Schwierigkeiten bei der Ermittlung der Client-Verbindungsinformationen haben und kann möglicherweise nicht die richtigen Antworten geben: Er kann die Anwendung sogar anhalten.
Damit die Webanwendung die SSL-Verschiebung zulässt, müssen Sie die folgende Regel hinzufügen.
# See clearly in the log if the application is setting up response for HTTP or HTTPS
capture response header Location   len 32
capture response header Set-Cookie len 32

# Provide client side connection info to application server over HTTP header
http-request set-header X-Forwarded-Proto https if  { ssl_fc }
http-request set-header X-Forwarded-Proto http  if !{ ssl_fc }
Der Load Balancer fügt den folgenden Header ein, wenn die Verbindung über SSL hergestellt wird.
X-Forwarded-Proto: https
Der Load Balancer fügt den folgenden Header ein, wenn die Verbindung über HTTP hergestellt wird.
X-Forwarded-Proto: http

Sperren spezifischer URLs

Sie können Anforderungen mit bestimmten Schlüsselwörtern in der URL sperren. Die nachfolgend aufgeführte Beispielregel überprüft, ob Anforderungen mit /private oder /finance beginnt und blockiert jede Anforderung mit solchen Begriffen.

# Check if the request starts with "/private" or "/finance" (case insensitive)
acl block_url_list path_beg -i /private /finance

# If the request is part of the list forbidden urls,reply "Forbidden"(HTTP response code
 403)
http-request deny if block_url_list

HTTP-Umleitung zur Authentifizierung ohne Cookies

Sie können eine Client-Anforderung, die über kein Cookie verfügt, für eine Authentifizierung umleiten. Die nachfolgend aufgeführte Beispielregel überprüft die Authentizität der HTTP-Anforderung und das Vorhandensein von Cookies in der Kopfzeile. Wenn die Anforderung über keine Cookies verfügt, leitet die Regel sie zu / authent.php zur Authentifizierung um.

acl authent_url url /authent.php
acl cookie_present hdr_sub(cookie) cookie1=
redirect prefix /authent.php if !authent_url !cookie_present

Umleitung zur Standardseite

Sie können die Client-Anforderung / zu einer Standardseite umleiten. Die nachfolgend aufgeführte Beispielregel überprüft, ob die HTTP-Anforderung / lautet, und leitet diese dann gegebenenfalls zu einer Standardanmeldeseite um.

acl default_url url /
redirect location /login.php if default_url

Umleitung zur Wartungs-Site

Wenn der primäre Pool inaktiv ist, können Sie einen Wartungsserverpool verwenden und die URL zur Wartungs-Website umleiten.

redirect location http://maitenance.xyz.com/maintenance.htm

NT LAN Manager- (NTLM-)Authentifizierung

Standardmäßig schließt NSX auf der Serverseite die TCP-Verbindung nach jeder Anforderung. Wenn Sie die Serversitzung nach einer Anforderung nicht schließen möchten, kann die Serversitzung aktiv und durch das NTLM-Protokoll gesichert bleiben.

no option http-server-close

Standardmäßig behält NSX auf dem Client die TCP-Verbindung bei, die zwischen Anforderungen eingerichtet wurde. Mit der Option „X-Forwarded-For“ wird die Sitzung jedoch nach jeder Anforderung geschlossen. Mit der im Folgenden dargestellten Option bleibt die Clientverbindung zwischen Anforderungen geöffnet, auch wenn XFF konfiguriert ist.

no option httpclose

Ersetzen der Serverkopfzeile

Sie können die vorhandenen Antwortserverkopfzeilen löschen und diese durch einen anderen Server ersetzen. Die im Folgenden aufgeführte Beispielregel löscht die Serverkopfzeile und ersetzt diese mit dem NGINX-Webserver, der als Reverseproxyserver für HTTP-, HTTPS-, SMTP-, POP3- und IMAP-Protokolle sowie für den HTTP-Cache und als Load Balancer dienen kann.

rspidel Server
rspadd Server:\ nginx

Ändern der Umleitung

Sie können den Adressheader von HTTP in HTTPS ändern. Die nachfolgend dargestellte Beispielregel ermittelt den Adressheader und ersetzt HTTP mit HTTP.

rspirep ^Location:\ http://(.*)  Location:\ https://\1

Auswählen bestimmter Pools auf der Basis eines Hosts

Sie können Anforderungen mit einem bestimmten Host zu definierten Pools umleiten. Das nachfolgend aufgeführte Beispiel überprüft die Anforderungen auf bestimmte Hosts wie app1.xyz.com, app2.xyz.com und host_any_app3 und leitet diese Anforderungen jeweils zu den definierten Pools pool_app1 oder pool_app2 und pool_app3 um. Alle anderen Anforderungen werden zu vorhandenen, im virtuellen Server definierten Pools umgeleitet.

acl host_app1 hdr(Host) -i app1.xyz.com
acl host_app2 hdr(Host) -i app2.xyz.com
acl host_any_app3 hdr_beg(host) -i app3

Verwenden Sie einen bestimmten Pool für jeden einzelnen Hostnamen.

use_backend pool_app1 if host_app1
use_backend pool_app2 if host_app2
use_backend pool_app3 if host_any_app3

Auswählen bestimmter Pools auf der Basis von URLs

Sie können Anforderungen mit URL-Schlüsselwörtern zu bestimmten Pools umleiten. Die nachfolgend aufgeführte Beispielregel überprüft, ob die Anforderungen mit /private oder /finance beginnen und leitet diese Anforderungen dann zu den definierten Pools pool_private oder pool_finance um. Alle anderen Anforderungen werden zu vorhandenen, im virtuellen Server definierten Pools umgeleitet.

acl site_private path_beg -i /private
acl site_finance path_beg -i /finance
use_backend pool_private if site_private
use_backend pool_finance if site_finance

Umleitung bei inaktivem primären Pool

Wenn Ihre Server im primären Pool inaktiv sind, können Sie Benutzer zu den Servern im sekundären Pool umleiten. Die nachfolgend aufgeführte Beispielregel überprüft, ob pool_production inaktiv ist und überträgt die Benutzer dann in diesem Fall zu pool_sorry_server.

acl pool_production_down nbsrv(pool_production) eq 0
use_backend pool_sorry_server if pool_production_down

Positivliste für die TCP-Verbindung

Sie können Client-IP-Adressen für den Zugriff auf Ihren Server sperren. Die im Folgenden dargestellte Beispielregel blockiert die definierte IP-Adresse und setzt die Verbindung zurück, wenn die Client-IP-Adresse nicht in der Positivliste enthalten ist.

acl whitelist src 10.10.10.0 20.20.20.0
tcp-request connection reject if !whitelist

Aktivieren von sslv3 und tlsv1

Standardmäßig sind die Dienstmonitorerweiterungen sslv3 und tlsv1 deaktiviert. Sie können diese mit der nachfolgend dargestellten Anwendungsregel aktivieren.

sslv3 enable
tlsv1 enable

Konfigurieren des Zeitlimits für die Clientsitzung

Der Wert für das Sitzungszeitlimit stellt die maximal zulässige Dauer der Verbindungsinaktivität auf der Clientseite dar. Dieses Zeitlimit für die Inaktivität gilt in den Fällen, in denen Daten vom Client bestätigt oder gesendet werden sollen. Im HTTP-Modus wird dieses Zeitlimit insbesondere sowohl in der ersten Phase berücksichtigt, wenn der Client die Anforderung sendet, als auch während der Antwort, wenn der Client die vom Server gesendeten Daten liest. Das Standardzeitlimit beträgt fünf Minuten.

Die nachfolgende Beispielregel legt den Zeitraum auf 100 Sekunden fest.

timeout client 100s

Der Zeitwert kann als Ganzzahl in Millisekunden, Sekunden, Minuten, Stunden oder Tagen festgelegt werden.

Umleitung zur HTTPS-Site

Sie können die Clients, die HTTP nutzen, zu derselben Seite mit HTTPS umleiten.

# Redirect all HTTP requests to same URI but HTTPS redirect scheme
https if !{ ssl_fc }

Eine andere Möglichkeit lautet wie folgt:

rspirep ^Location:\ http://(.*) Location:\ https://\1 

Nicht authentische Clients umleiten

Leiten Sie die Client-Anforderungen an „/authent.php“ um, wenn sie kein Cookie haben.

# Check the HTTP request if request is "/authent.php"
acl authent_url url /authent.php
# Check the cookie "cookie1" is present
acl cookie_present hdr_sub(cookie) cookie1=
# If the request is NOT "/authent.php" and there is no cookie, then redirect to "/authent.php"
redirect prefix /authent.php if !authent_url !cookie_present 

HTTP-Antwortkopfzeile umschreiben

Ersetzen Sie die Antwortserverkopfzeile „Server“ durch den Wert „nginx“.

# Delete the existing Response Server header "Server"
rspidel Server
# Add the Response Server header "Server" with the value "nginx"
rspadd Server:\ nginx

Sorry Server

Falls die Server im primären Pool alle ausgefallen sind, verwenden Sie Server aus dem sekundären Pool.

# detect if pool "pool_production" is still up
acl pool_production_down nbsrv(pool_production) eq 0
# use pool "pool_sorry_server" if "pool_production" is dead
use_backend pool_sorry_server if pool_production_down
# Option 1: # Redirect everything to maintenance site
redirect location http://maintenance.xyz.com/maintenance.htm
# Option 2: #Use a specific maintenance server pool and rewrite all URLs to maintenance.php
acl match_all always_true
use_backend maint_pool if match_all
reqirep ^GET\(.*)\HTTP/(.*) GET\ /maintenance.php\ HTTP/\2