È opinione diffusa tra i miei colleghi di Edgenexus che, sebbene i bilanciatori di carico F5 LTM siano estremamente potenti e flessibili, la dipendenza dall’uso di scripting iRules per eseguire alcune funzioni di base porti a una complessità non necessaria.
Basta fare una ricerca online su F5 iRules per scoprire il dolore e l’angoscia che molti professionisti IT devono affrontare nel processo di creazione di iRules funzionali. Sebbene sia vero che l’espansione della funzionalità “Criteri di traffico locale” nelle recenti versioni del software F5 abbia eliminato in parte la necessità di creare iRules per le comuni funzioni di manipolazione delle intestazioni HTTP, molti utenti sono ancora bloccati da iRules legacy nella loro configurazione di sistema.
Le politiche di traffico locale non sembrano consentire la manipolazione dei dati HTML, anche se le politiche Stream lo fanno, ma sono piuttosto complicate e difficili da controllare. Per impostazione predefinita, queste politiche influenzano il traffico in entrambe le direzioni allo stesso modo, anche se di solito non è auspicabile. Ciò significa che è necessario tornare a iRules per eseguire funzioni come la sostituzione del testo del corpo dell’URL da http:// a https://, che potrebbe essere necessaria insieme al reindirizzamento da http:// a https, che può essere eseguito utilizzando i Criteri di traffico locale.
Entra in Edgenexus flightPATH – Gestione del traffico semplificata
Noi di Edgenexus siamo giustamente orgogliosi della potenza e della semplicità di configurazione della nostra funzione di manipolazione HTTP flightPATH Layer 7.
Se sei già un utente di F5 e utilizzi iRules per la manipolazione di HTTP o HTML, saremmo lieti di avere l’opportunità di offrirti una dimostrazione del bilanciatore di carico Edgenexus ALB-X e di mostrarti quanto sia semplice configurare flightPATH per realizzare alcune funzioni relativamente complesse. Ci piacerebbe essere messi alla prova per aiutarti a tradurre le tue funzioni iRules esistenti in regole flightPATH.
A titolo di esempio, abbiamo riprodotto di seguito una selezione di iRules di F5 con le schermate equivalenti di configurazione delle regole flightPATH di Edgenexus.
IP di origine Indirizzo del server dei contenuti
Ecco un esempio di come F5 iRules può essere utilizzato per indirizzare gli utenti di un certo intervallo di indirizzi IP verso un Server Pool e quelli di un altro intervallo verso un altro Server Pool.
F5:
| Nome: | IP_Choice |
| Definizione: | when HTTP_REQUEST { if { ( [IP::addr [IP::client_addr] uguale a 24.24.15.100] ) o ( [IP::addr [IP::client_addr] uguale a 10.1.1.2] ) } { pool pool2 } } |
Edgenexus:
- Crea una nuova regola flightPATH con il nome IP_Choice_Pool_1 tramite la GUI web. Aggiungi una descrizione concisa per poter identificare la funzione svolta dalla regola flightPATH.
- Aggiungi una nuova condizione, selezionando l’IP di origine dall’ampio elenco a discesa. Seleziona “Fa” dal menu a tendina Senso. Un’opzione è quella di selezionare Inizio dall’elenco a discesa Controllo (in alternativa puoi utilizzare altre opzioni come RegEx per ottenere una maggiore flessibilità per il “Valore” dell’indirizzo IP). Inserisci l’intervallo IP iniziale nella casella Valore.
- Aggiungi una nuova azione. Dalla casella a discesa Azione scegli l’opzione Usa server (c’è anche l’opzione Usa server sicuro, se necessario). Nella casella Destinazione inserisci l’indirizzo IP e la porta della destinazione richiesta, che di solito è un’altra interfaccia del Servizio Virtuale per consentire il bilanciamento del carico su un altro pool di server reali.
Reindirizzamento da HTTP a HTTPS
Sebbene F5 offra un’alternativa all’uso di iRules per eseguire il reindirizzamento da HTTP a HTTPs, ci sono molti casi in cui si continua a usare iRules per questa funzione. iRules consente anche una maggiore personalizzazione dei parametri di reindirizzamento.
F5:
| Nome: | Reindirizzamento HTTP_HTTPs |
| Definizione: | quando HTTP_REQUEST { HTTP::redirect “https://[HTTP::host][HTTP::uri]” } |
Edgenexus:
- Crea una nuova regola flightPATH con il nome Reindirizzare HTTP a HTTPS tramite la GUI web. Aggiungi una descrizione concisa per poter identificare la funzione svolta dalla regola flightPATH.
- Per la maggior parte delle applicazioni, il requisito di eseguire il reindirizzamento da HTTP a HTTPS deve essere eseguito su tutto il traffico che colpisce il servizio HTTP. In questo caso non è necessario creare una regola di condizione. La creazione di regole di condizione è molto flessibile se la regola flightPATH deve riguardare solo un determinato traffico.
- Aggiungi una nuova azione scegliendo Redirect 302 dalla casella a discesa Azione (è disponibile anche Redirect 301). Edgenexus ALB-X crea automaticamente delle variabili per alcuni parametri chiave del traffico elaborato dall’ALB-X, tra cui l’host, il percorso e la stringa di query. Nella casella Destinazione inserisci i dettagli della destinazione della richiesta. In questo caso precede la voce https:// e utilizza le variabili $host$$path$$querystring$ per inserire i dati della richiesta http originale. Come puoi vedere, c’è la possibilità di definire una destinazione completamente diversa, se necessario.
Maschera i numeri delle carte di credito
Ecco un esempio della complessità di iRules e del modo in cui F5 gestisce la manipolazione del corpo HTML.
F5:
| Nome: | Mascheramento del numero di carta di credito |
| Definizione: | quando HTTP_REQUEST { # Impedisce al server di inviare una risposta compressa # rimuovi le offerte di compressione dal client HTTP::header rimuovere “Accept-Encoding”. # Non permettere che i dati di risposta siano suddivisi in pacchetti (chunked). if { [HTTP::version] eq “1.1” } { # Forza il downgrade a HTTP 1.0, ma continua a consentire le connessioni keep-alive. # Poiché HTTP 1.1 è keep-alive per impostazione predefinita, mentre 1.0 non lo è, # dobbiamo assicurarci che le intestazioni riflettano lo stato keep-alive. # Verifica se si tratta di una connessione keep alive if { [HTTP::header is_keepalive] } { # Sostituisci il valore dell’intestazione della connessione con “Keep-Alive”. HTTP::header replace “Connection” “Keep-Alive” } # Imposta la versione della richiesta lato server a 1.0 # Questo costringe il server a rispondere senza fare il “chunking”. HTTP::versione “1.0” } } quando HTTP_RESPONSE { # Controlla solo le risposte che hanno un contenuto di tipo testo (text/html, text/xml, text/plain, ecc.). if { [HTTP::header “Content-Type”] inizia_con “text/” } { # Ottenere la lunghezza del contenuto in modo da poter raccogliere i dati (da elaborare nell’evento HTTP_RESPONSE_DATA) # Limita la raccolta a 1Mb (1048576 meno un po’ di spazio) – Vedi SOL6578 per i dettagli if { [HTTP::header exists “Content-Length”] } { if { [HTTP::header “Content-Length”] > 1048000 }{ # Lunghezza del contenuto superiore a 1Mb quindi raccogli 1Mb imposta lunghezza_contenuto 1048000 } else { # Lunghezza del contenuto inferiore a 1Mb quindi raccogli la lunghezza effettiva imposta lunghezza_contenuto [HTTP::header “Content-Length”] } } else { # La risposta non ha un’intestazione Content-Length, quindi usa il valore predefinito di 1Mb. imposta lunghezza_contenuto 1048000 } # Non raccogliere il contenuto se il valore dell’intestazione Content-Length è 0 if { $content_length > 0 } { HTTP::collect $lunghezza_contenuto } } } quando HTTP_RESPONSE_DATA { # Trova TUTTI i numeri di carta di credito possibili in un solo passaggio. set card_indices [regexp -all -inline -indices {(?:3[4|7]\d{2})(?:[ ,-]?(?:\d{5}(?:\d{1})?)){2}|(?:4\d{3})(?:[ ,-]?(?:\d{4})){3}|(?:5[1-5]\d{2})(?:[ ,-]?(?:\d{4})){3}|(?:6011)(?:[ ,-]?(?:\d{4})){3}}\ [HTTP::payload]] foreach card_idx $card_indices { imposta card_start [lindex $card_idx 0] imposta fine carta [lindex $card_idx 1] set card_len [expr {$card_end – $card_start + 1}] set card_number [range di stringhe [HTTP::payload] $card_start $card_end] # Rimuovi il trattino o lo spazio se esistono e conta le occorrenze nei ritagli di variabili. imposta i ritagli [regsub -all {[-]} $numero_carta “” numero_carta] # Aggiusta la variabile card_len ma conservala per un uso successivo. set new_card_len [expr {$card_len – $cutouts}] set double [expr {$new_card_len & 1}] imposta chksum 0 imposta isCard invalido # Calcola MOD10 for { set i 0 } { $i < $new_card_len } { incr i } { imposta c [string index $card_number $i] if {($i & 1) == $doppio} { if {[incr c $c] >= 10} {incr c -9} } incr chksum $c } # Determina il tipo di carta switch [string index $card_number 0] { 3 { set tipo AmericanExpress } 4 { set type Visa } 5 { set type MasterCard } 6 { set type Discover } default { set type Unknown } } # Se il numero della carta è valido, maschera i numeri con delle X. if { ($chksum % 10) == 0 } { imposta isCard valido HTTP::payload replace $card_start $card_len [string repeat “X” $card_len] } # Risultati del registro log local0. “Trovato $isCard $tipo CC# $numero_carta”. } } |
Edgenexus:
- Crea una nuova regola flightPATH e fornisci una descrizione significativa
- Questo è un altro esempio in cui la corrispondenza delle condizioni potrebbe non essere necessaria, in quanto normalmente si desidera proteggere le risposte del server. L’opzione è ovviamente disponibile se necessaria.
- Aggiungi una nuova “Azione” e scegli “Corpo Sostituisci tutto” dal menu a discesa. Vengono utilizzate le Espressioni Regolari per poter individuare il testo di destinazione da sostituire con questa azione. Usa \b(?:\d[ \t-]?){12}\b come obiettivo per individuare e sostituire le prime 12 cifre dei numeri di carta di credito. Nel campo Dati inserisci xxxx-xxxx-xxxx come testo sostitutivo. Questo lascerà intatte le ultime 4 cifre come identificativo.
- Ripeti il processo sopra descritto per altri tipi di dati sensibili come i numeri di previdenza nazionale utilizzando \b(?:\d[ \t-]?){7}\b sostituito da xxx-xxxx e \b(?:\d[ \t-]?){6}\b sostituito da xxx.xxx
- Con un uso accorto delle espressioni regolari è possibile abbinare e mascherare un’ampia varietà di sequenze di caratteri semplicemente utilizzando l’azione Sostituisci corpo. Body Replace First e Body Replace Last sono altre opzioni di azione che possono essere utilizzate quando è necessario sostituire solo la prima o l’ultima istanza di una sequenza di caratteri in una pagina.
Rimuovere le intestazioni X potenzialmente compromettenti per la sicurezza
Spesso viene indicata come buona pratica quella di evitare di fornire informazioni non necessarie sull’infrastruttura server utilizzata per la distribuzione di un’applicazione, rimuovendo alcune intestazioni HTTP inserite di default dall’applicazione o dalla tecnologia del server. Più un hacker conosce il sistema che sta cercando di sfruttare, più è facile. Spesso c’è un intervallo di tempo tra la pubblicazione delle vulnerabilità del sistema e la realizzazione delle patch. È in questo periodo che i sistemi sono più a rischio e che il processo di oscuramento dei dettagli della piattaforma di distribuzione delle applicazioni è più utile.
Molte delle informazioni non necessarie sono contenute negli X-Header. La seguente iRule esegue una rimozione generalizzata degli X-Header che potrebbe non essere auspicabile.
F5:
| Nome: | HTTP X-Server Header Removal |
| Definizione: | quando HTTP_RESPONSE { # Rimuovere tutte le istanze dell’intestazione Server HTTP::header remove Server # Rimuovi tutte le intestazioni che iniziano con x- foreach header_name [HTTP::header names] { if {[string match -nocase x-* $header_name]}{ HTTP::header remove $nome_intestazione } } } |
Edgenexus:
- Crea una nuova regola flightPATH con un nome significativo, ad esempio Rimuovi intestazioni HTTP.
- Questo è un esempio di regola flightPATH in cui probabilmente non è necessaria una corrispondenza di condizioni. Se necessario, è disponibile una serie completa di criteri di selezione.
- Aggiungi una nuova azione “Rimuovi intestazione risposta”, nel campo Destinatario inserisci il valore dell’intestazione da rimuovere. Aggiungi una voce dell’azione Rimuovi intestazione risposta per definire ciascuno dei campi dell’intestazione che desideri vengano mascherati dalle risposte del server. Un’azione generalizzata di rimozione di tutte le intestazioni personalizzate con prefisso X potrebbe avere un effetto negativo, quindi flightPATH ti chiede di definire le intestazioni specifiche che devono essere rimosse.
- Applica il flightPATH creato a ciascuno dei servizi in cui è richiesta l’azione.
Applicazione delle regole flightPATH ai servizi virtuali
flightPATH è uno strumento di manipolazione HTTP molto potente ma semplice da usare. Puoi creare una “libreria” di regole flightPATH per eseguire varie azioni sul traffico HTTP mentre attraversa il dispositivo di bilanciamento del carico ALB-X. È possibile applicare più regole flightPATH a un servizio virtuale. Le regole flightPATH vengono elaborate nell’ordine in cui vengono applicate al servizio. Alcune regole flightPATH terminano l’elaborazione. Puoi usare il drag and drop per riorganizzare l’ordine e assicurarti che tutte le azioni vengano eseguite come richiesto. Sono disponibili registrazioni e tracciati flightPATH completi che consentono il debug delle operazioni flightPATH. edgeNEXUS può offrire servizi professionali per assistere nella traduzione e creazione di regole flightPATH più complesse.
Vuoi saperne di più?
Per maggiori informazioni sulla manipolazione del traffico di Edgenexus clicca qui.
Per scaricare una prova gratuita di ALB-X clicca qui.
Ci piacerebbe avere l’opportunità di dimostrare le funzionalità di Edgenexus ALB-X e flightPATH. Richiedi qui una dimostrazione tecnica rapida e personalizzata.
