Règles d'application couramment utilisées.

Redirection HTTP/HTTPS basée sur une condition

Un profil d'application vous permet de spécifier une redirection HTTP/HTTPS, qui redirige toujours le trafic indépendamment des URL de demande. Vous avez également la possibilité de définir les conditions dans lesquelles le trafic HTTP/HTTPS doit être redirigé.
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

Routage par nom de domaine

Vous pouvez créer une règle d'application pour diriger les demandes vers un pool d'équilibrage de charge en fonction du nom de domaine. La règle suivante dirige les demandes de foo.com vers pool_1, et les demandes de bar.com vers 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

Équilibrage de charge et protection de Microsoft RDP

Dans l'exemple de scénario suivant, l'équilibrage de charge dirige un nouvel utilisateur vers le serveur le moins chargé et reprend une session interrompue. L'adresse IP de l'interface interne de NSX Edge pour ce scénario est 10.0.0.18, l'adresse IP de l'interface interne est 192.168.1.1 et les serveurs virtuels sont 192.168.1.100, 192.168.1.101 et 192.168.1.102.
  1. Créez un profil d'application pour le trafic TCP avec persistance MSRDP.
  2. Créez un moniteur d'intégrité TCP (tcp_monitor).
  3. Créez un pool (nommé rdp-pool) avec les adresses IP 192.168.1.100:3389, 192.168.1.101:3389 et 192.168.1.102:3389 en tant que membres.
  4. Associez tcp_monitor à rdp-pool.
  5. Créez la règle d'application suivante.
    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. Créez un serveur virtuel (nommé rdp-vs).
  7. Associez le profil d'application à ce serveur virtuel et ajoutez la règle d'application créée à l'étape 4.

La nouvelle règle d'application appliquée sur le serveur virtuel protège les serveurs RDP.

Journalisation avancée

Par défaut, l'équilibrage de charge NSX prend en charge la journalisation de base. Vous pouvez créer une règle d'application comme suit pour afficher des messages de journalisation détaillés pour la résolution des problèmes.
 # 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
Une fois que vous avez associé la règle d'application au serveur virtuel, les journaux comportent des messages détaillés, comme dans l'exemple suivant.
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" ""
Pour résoudre les problèmes liés au trafic HTTPS, il peut s'avérer nécessaire d'ajouter d'autres règles. La plupart des applications Web utilisent des réponses 301/302 avec un en-tête d'emplacement pour rediriger le client vers une page (la plupart du temps après une connexion ou un appel POST) et nécessitent également un cookie d'application. C'est la raison pour laquelle votre serveur d'application peut non seulement avoir des difficultés à obtenir les informations de connexion du client, mais également ne pas être en mesure de donner les réponses correctes : il peut même arrêter le fonctionnement de l'application.
Pour autoriser les applications Web à prendre en charge le déchargement SSL, ajoutez la règle suivante.
# 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 }
L'équilibreur de charge insère l'en-tête suivant lorsque la connexion est établie via SSL.
X-Forwarded-Proto: https
L'équilibreur de charge insère l'en-tête suivant lorsque la connexion est établie via HTTP.
X-Forwarded-Proto: http

URL spécifiques à un bloc

Vous pouvez bloquer des demandes contenant des mots-clés spécifiques dans l'URL. L'exemple de règle suivant vérifie si la demande commence par /private ou /finance et bloque les demandes qui contiennent ces termes.

# 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

Redirection HTTP de l'authentification s'il n'y a pas de cookies

Vous pouvez rediriger une demande de client ne contenant pas de cookie pour obtenir une authentification. L'exemple de règle suivant vérifie si la demande HTTP est authentique et si son en-tête contient des cookies. Si la demande ne contient pas de cookies, la règle redirige la demande vers / authent.php pour authentification.

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

Redirection de page par défaut

Vous pouvez rediriger la demande du client / vers une page par défaut. L'exemple de règle suivant vérifie si la demande HTTP est / et la redirige vers une page de connexion par défaut.

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

Redirection vers un site de maintenance

Lorsque le pool principal est inactif, vous pouvez utiliser un pool de serveurs de maintenance et rediriger l'URL vers le site Web de maintenance.

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

Authentification NTLM (NT LAN Manager)

Par défaut, côté serveur, NSX ferme la connexion TCP après chaque demande. Lorsque vous ne voulez pas fermer la session de serveur après chaque demande, vous pouvez laisser la session de serveur active et la sécuriser avec le protocole NTLM.

no option http-server-close

Par défaut, côté client, NSX maintient la connexion TCP établie entre les demandes. Cependant avec l'option « X-Forwarded-For », la session est fermée après chaque demande. L'option suivante maintient la connexion client ouverte entre les demandes, même si XFF est configuré.

no option httpclose

Remplacer l'en-tête de serveur

Vous pouvez supprimer l'en-tête de serveur de réponse existant et le remplacer par un autre serveur. L'exemple de règle suivant supprime l'en-tête de serveur et le remplace par le serveur Web NGINX qui peut agir en tant que serveur proxy inverse pour les protocoles HTTP, HTTPS, SMTP, POP3 et IMAP, le cache HTTP et un équilibrage de charge.

rspidel Server
rspadd Server:\ nginx

Réécrire la redirection

Vous pouvez réécrire l'en-tête Emplacement HTTP en HTTPS. L'exemple de règle suivant identifie l'en-tête Emplacement et remplace HTTP par HTTP.

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

Sélectionner un pool spécifique en fonction de l'hôte

Vous pouvez rediriger des demandes avec un hôte spécifique vers des hôtes définis. L'exemple de règle suivant recherche la demande des hôtes spécifiques app1.xyz.com, app2.xyz.com et host_any_app3 et redirige ces demandes respectivement vers des pools définis, pool_app1 ou pool_app2 et pool_app3. Toutes les autres demandes sont redirigées vers des pools existants définis dans le serveur virtuel.

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

Utilisez un pool spécifique pour chaque nom d'hôte.

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

Sélectionner un pool spécifique en fonction d'URL

Vous pouvez rediriger les demandes avec des mots-clés d'URL vers des pools spécifiques. L'exemple de règle suivant vérifie si la demande commence par /private ou /finance et redirige ces demandes vers des pools définis, pool_private ou pool_finance. Toutes les autres demandes sont redirigées vers des pools existants définis dans le serveur virtuel.

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

Rediriger lorsque le pool principal est inactif

Si vos serveurs dans le pool principal sont inactifs, vous pouvez rediriger des utilisateurs pour qu'ils utilisent les serveurs dans le pool secondaire. L'exemple de règle suivant vérifie si pool_production est inactif et transfère les utilisateurs vers pool_sorry_server.

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

Mettre la connexion TCP sur la liste blanche

Vous pouvez empêcher des adresses IP de client d'accéder à votre serveur. L'exemple de règle suivant bloque l'adresse IP définie et réinitialise la connexion si l'adresse IP client ne se trouve pas sur la liste blanche.

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

Activer sslv3 et tlsv1

Les extensions de surveillance de service sslv3 et tlsv1 sont désactivées par défaut. Vous pouvez les activer avec la règle d'application suivante.

sslv3 enable
tlsv1 enable

Configurer le délai d'expiration de la session du client

Le délai d'expiration de la session est la durée maximale d'inactivité de la connexion du côté du client. Le délai d'expiration de l'inactivité s'applique lorsque le client est sensé accuser réception ou envoyer des données. En mode HTTP, il est particulièrement important de prendre en compte ce délai d'expiration pendant la première phase, lorsque le client envoie la demande et pendant la réponse lorsque le client lit les données envoyées par le serveur. La valeur du délai d'expiration par défaut est de cinq minutes.

L'exemple de règle suivant définit le délai d'expiration sur 100 secondes.

timeout client 100s

La durée peut être définie sous la forme d'un entier avec des millisecondes, des secondes, des minutes, des heures ou des jours.

Redirection vers un site HTTPS

Vous pouvez rediriger les clients accédant à une page HTTP vers la même page sur HTTPS.

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

Autre option :

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

Redirection de clients non authentiques

Redirigez les demandes des clients vers « /authent.php » s'ils n'ont pas de cookie.

# 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 

Réécriture de l'en-tête de réponse HTTP

Remplacez l'en-tête de serveur de réponse « Server » par la valeur « nginx ».

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

Serveur « Désolé »

Dans le cas où les serveurs du pool principal sont tous inactifs, utilisez les serveurs du pool secondaire.

# 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