Cómo migrar F5 iRules a Edgenexus flightPATH

Es una creencia muy extendida entre mis colegas de Edgenexus que, aunque los equilibradores de carga LTM de F5 son extremadamente potentes y flexibles, la dependencia del uso de scripts iRules para realizar algunas funciones básicas conduce a una complejidad innecesaria.

Sólo tienes que hacer una búsqueda en Internet sobre iRules de F5 para descubrir el dolor y la angustia que supone para muchos profesionales de TI el proceso de creación de iRules funcionales. Aunque es cierto que la ampliación de la funcionalidad «Políticas de tráfico local» en las últimas versiones del software de F5 ha eliminado parte de la necesidad de crear iRules para funciones comunes de manipulación de cabeceras HTTP, hay muchos usuarios que siguen atascados con iRules heredadas en la configuración de su sistema.

Las Políticas de Tráfico Local no parecen permitir la manipulación de datos HTML, aunque las políticas de Flujo sí lo hacen, son bastante toscas y difíciles de controlar. Por defecto, afectan al tráfico en ambas direcciones de la misma manera, aunque esto no suele ser deseable. Esto significa volver a iRules para realizar funciones como la sustitución de un enlace de texto del cuerpo de la URL de http:// a https://, que puede ser necesaria junto con una redirección de http:// a https, que puede realizarse utilizando las Políticas de Tráfico Local.

Entra en Edgenexus flightPATH – La gestión del tráfico más fácil

En Edgenexus, estamos justificadamente orgullosos de la potencia y sencillez de configuración de nuestra función de manipulación HTTP flightPATH Capa 7.

Si ya eres usuario de F5 y utilizas iRules para manipular HTTP o HTML, nos encantaría tener la oportunidad de hacerte una demostración del equilibrador de carga ALB-X de Edgenexus y mostrarte lo sencillo que es configurar flightPATH para conseguir algunas funciones relativamente complejas. Nos gustaría que nos pusieras a prueba para ayudarte a traducir tus funciones iRules existentes a reglas flightPATH.

A modo de ejemplo, reproducimos a continuación una selección de iRules de F5 con las capturas de pantalla equivalentes de configuración de reglas flightPATH de Edgenexus.

IP de origen Dirección del servidor de contenidos

He aquí un ejemplo de cómo se puede utilizar F5 iRules para dirigir a los usuarios de un determinado rango de direcciones IP a un Grupo de Servidores y a los de otro rango a otro Grupo de Servidores.

F5:

Nombre:	Elección_IP
Definición:	when HTTP_REQUEST { if { ( [IP::addr [IP::client_addr] igual a 24.24.15.100] ) or ( [IP::addr [IP::client_addr] igual a 10.1.1.2] ) } { pool pool2 } }

Edgenexus:

haz clic aquí para ampliar

Crea una nueva regla flightPATH con el nombre IP_Choice_Pool_1 a través de la GUI Web. Añade una descripción concisa para poder identificar cuál es la función que realiza la regla flightPATH.
Añade una nueva Condición, seleccionando IP de Origen en la extensa lista desplegable. Selecciona «Hace» en la lista desplegable Sentido. Una opción es seleccionar Inicio en la lista desplegable Comprobar (como alternativa puedes utilizar otras opciones, como RegEx, para dar más flexibilidad al «Valor» de la dirección IP). Introduce el rango de IP de inicio en la casilla Valor.
Añade una Nueva Acción. En el cuadro desplegable Acción, elige la opción Utilizar Servidor (también existe la opción Utilizar Servidor Seguro, si es necesario). En la casilla Destino introduce la dirección IP y el puerto del destino requerido, que suele ser otra interfaz de Servicio Virtual para permitir el equilibrio de carga en otro grupo de servidores reales.

Redireccionamiento HTTP a HTTPS

Aunque F5 dispone ahora de una alternativa al uso de iRules para realizar la redirección de HTTP a HTTPs, hay muchos casos en los que la gente sigue utilizando iRules para esta función. iRules también permite una mayor personalización de los parámetros de redirección.

F5:

Nombre:	Redirección HTTP_HTTPs
Definición:	cuando HTTP_REQUEST { HTTP::redirect «https://[HTTP::host][HTTP::uri]» }

Edgenexus:

haz clic aquí para ampliar

Crea una nueva regla flightPATH con el nombre Redirigir HTTP a HTTPS a través de la GUI Web. Añade una descripción concisa para poder identificar cuál es la función que realiza la regla flightPATH.
Para la mayoría de las aplicaciones, el requisito de realizar la redirección de HTTP a HTTPS debe realizarse en todo el tráfico que llega al servicio HTTP. En este caso no es necesario crear ninguna regla de condición. Existe una gran flexibilidad para crear reglas de condición si la regla flightPATH sólo debe afectar a cierto tráfico.
Añade una nueva Acción eligiendo Redirigir 302 en el cuadro desplegable Acción (también está disponible Redirigir 301). El ALB-X de Edgenexus crea automáticamente variables para determinados parámetros clave del tráfico procesado por el ALB-X, entre los que se incluyen el host, la ruta y la cadena de consulta. En la casilla Destino introduce los detalles de a dónde debe redirigirse la petición. En este caso precede a la entrada https:// y utiliza las variables $host$$path$$querystring$ para insertar los datos de la petición http original. Como puedes ver, aquí hay flexibilidad para definir un destino completamente distinto si es necesario.

Enmascarar números de tarjeta de crédito

He aquí un ejemplo de las complejidades de iRules y de la forma en que F5 maneja la manipulación del cuerpo HTML.

F5:

Nombre:

Enmascaramiento del número de tarjeta de crédito

Definición:

cuando HTTP_REQUEST {

# Evitar que el servidor envíe una respuesta comprimida
# eliminar las ofertas de compresión del cliente
HTTP::header eliminar «Accept-Encoding»

# No permitir que los datos de respuesta sean fragmentados
si { [HTTP::version] eq «1.1» } {

# Fuerza el downgrade a HTTP 1.0, pero sigue permitiendo conexiones keep-alive.
# Puesto que HTTP 1.1 es keep-alive por defecto, y 1.0 no lo es,
# tenemos que asegurarnos de que las cabeceras reflejan el estado keep-alive.

# Comprueba si se trata de una conexión keep alive
si { [HTTP::header is_keepalive] } {

# Sustituye el valor de la cabecera de conexión por «Keep-Alive»
HTTP::header sustituir «Conexión» «Keep-Alive»
}

# Establece la versión de la petición del lado del servidor en 1.0
# Esto obliga al servidor a responder sin trocear
HTTP::versión «1.0»
}
}
cuando HTTP_RESPONSE {

# Comprueba sólo las respuestas que tengan un tipo de contenido de texto (text/html, text/xml, text/plain, etc.).
si { [HTTP::header «Content-Type»] empieza_con «texto/» } {

# Obtén la longitud del contenido para que podamos recoger los datos (que se procesarán en el evento HTTP_RESPONSE_DATA)
# Limitar la recogida a 1Mb (1048576 menos un poco de sobra) – Ver SOL6578 para más detalles
si { [HTTP::header exists «Content-Length»] } {
si { [HTTP::header «Content-Length»] > 1048000 }{
# Content-Length over 1Mb so collect 1Mb
establecer longitud_contenido 1048000
} si no {
# Content-Length under 1Mb so collect actual length
establecer longitud_contenido [HTTP::header «Content-Length»]
}
} si no {
# La respuesta no tenía cabecera Content-Length, así que usa el valor por defecto de 1Mb
establecer longitud_contenido 1048000
}
# No recopilar contenido si el valor de la cabecera Content-Length era 0
if { $longitud_del_contenido > 0 } {
HTTP::collect $longitud_del_contenido
}
}
}
cuando HTTP_RESPONSE_DATA {
# Encuentra TODOS los posibles números de tarjeta de crédito de una sola vez
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 tarjeta_idx $tarjeta_indices {
establecer inicio_tarjeta [lindex $card_idx 0]
establecer fin_tarjeta [lindex $card_idx 1]
set tarjeta_len [expr {$final_tarjeta – $inicio_tarjeta + 1}]
set número_tarjeta [rango cadena [HTTP::payload] $inicio_tarjeta $fin_tarjeta]
# Elimina el guión o el espacio si existen y cuenta las apariciones en los recortes variables.
establecer recortes [regsub -all {[-]} $número_tarjeta «» número_tarjeta]
# Ajusta la variable card_len pero guárdala para usarla más adelante.
set nuevo_len_tarjeta [expr {$len_tarjeta – $recortes}]

set doble [expr {$nueva_len_tarjeta & 1}]
establecer chksum 0
set isCard inválido

# Calcula MOD10
for { set i 0 } { $i < $new_card_len } { incr i } {
set c [string index $card_number $i]
if {($i & 1) == $doble} {
si {[incr c $c] >= 10} {incr c -9}
}
incr chksum $c
}

# Determina el tipo de tarjeta
interruptor [string index $card_number 0] {
3 { set type AmericanExpress }
4 { set type Visa }
5 { set type MasterCard }
6 { set type Descubre }
default { set type Desconocido }
}

# Si el número de tarjeta es válido, entonces enmascara los números con X’s
if { ($chksum % 10) == 0 } {
set isCard válida
HTTP::payload replace $card_start $card_len [string repeat «X» $card_len]
}

# Resultados del registro
log local0. «Encontrado $isCard $tipo CC# $número_tarjeta»
}
}

Edgenexus:

haz clic aquí para ampliar

Crea una nueva regla flightPATH y proporciona una descripción significativa
Éste es otro ejemplo en el que la coincidencia de condiciones puede no ser necesaria, ya que normalmente querrás proteger cualquier respuesta del servidor. Por supuesto, existe la opción si es necesario.
Añade una nueva ‘Acción’ y elige ‘Cuerpo Reemplazar Todo’ en la opción del menú desplegable. Se hace uso de Expresiones Regulares para poder hacer coincidir el texto Objetivo a sustituir por esta acción. Utiliza \b(?:\d[ \t-]?){12}\b como objetivo para detectar y sustituir los 12 primeros dígitos de los números de las tarjetas de crédito. En el campo Datos introduce xxxx-xxxx-xxxx como texto de sustitución. Esto dejará intactos los 4 últimos dígitos habituales como identificador.
Repite el proceso anterior para otros tipos de datos sensibles, como los números de la Seguridad Social, utilizando \b(?:\d[ \t-]?){7}\b sustituido por xxx-xxxx y \b(?:\d[ \t-]?){6}\b sustituido por xxx.xxx
Con un uso juicioso de las expresiones regulares, se pueden emparejar y enmascarar una gran variedad de secuencias de caracteres simplemente utilizando la acción Reemplazar cuerpo. Reemplazar cuerpo primero y Reemplazar cuerpo último son otras opciones de acción que pueden utilizarse cuando sólo es necesario reemplazar la primera o la última instancia de una secuencia de caracteres en una página.

Elimina las cabeceras X que puedan comprometer la seguridad

A menudo se cita como buena práctica evitar proporcionar información innecesaria sobre la infraestructura del servidor utilizado para la entrega de una aplicación, eliminando determinadas cabeceras HTTP que la aplicación o la tecnología del servidor insertan por defecto. Cuanto más sepa un hacker sobre el sistema que pretende explotar, más fácil le resultará. A menudo hay un desfase entre la publicación de las vulnerabilidades del sistema y la aplicación de los parches. Es durante este periodo cuando los sistemas están más amenazados y cuando el proceso de ocultar los detalles de la plataforma de entrega de aplicaciones es más útil.

Mucha de la información innecesaria está contenida en los encabezados X. La siguiente iRule realiza una eliminación general de X-Headers que puede no ser deseable.

F5:

Nombre:	HTTP Eliminación del encabezado del servidor X
Definición:	cuando HTTP_RESPONSE { # Elimina todas las instancias de la cabecera Servidor HTTP::header eliminar Servidor # Elimina todas las cabeceras que empiecen por x- foreach nombre_cabecera [HTTP::header names] { si {[string match -nocase x-* $header_name]}{ HTTP::header eliminar $nombre_cabecera } } }

Edgenexus:

haz clic aquí para ampliar

Crea una nueva regla flightPATH con un nombre significativo, por ejemplo Eliminar cabeceras HTTP
Éste es un ejemplo de regla flightPATH en la que probablemente no se requiera ninguna coincidencia de condiciones. Hay un amplio conjunto de criterios de selección disponibles en caso necesario.
Añade una nueva acción para ‘Eliminar Encabezado de Respuesta’, en el campo Destino introduce el valor del encabezado a eliminar. Añade una entrada de acción Eliminar encabezado de respuesta para definir cada uno de los campos de encabezado que quieras enmascarar de las respuestas del servidor. Una acción general de eliminación de todas las cabeceras personalizadas con prefijo X podría tener, de hecho, un efecto perjudicial, por lo que flightPATH requiere que definas las cabeceras específicas que deben eliminarse.
Aplica el flightPATH creado a cada uno de los servicios donde se requiera la acción.

Aplicar reglas flightPATH a servicios virtuales

flightPATH es una herramienta de manipulación HTTP muy potente, pero fácil de usar. Puedes crear una «Biblioteca» de reglas flightPATH para realizar diversas acciones sobre el tráfico HTTP a medida que atraviesa el dispositivo equilibrador de carga ALB-X. Se pueden aplicar varias reglas flightPATH a un servicio virtual. Las reglas flightPATH se procesan en el orden en que se aplican al servicio. Algunas reglas flightPATH terminan el procesamiento. Puedes utilizar la función de arrastrar y soltar para reorganizar el orden y asegurarte de que todas las acciones se realizan según lo requerido. Se dispone de un completo registro y rastreo de flightPATH que permite depurar el funcionamiento de flightPATH. edgeNEXUS puede ofrecer servicios profesionales para ayudar con la traducción y creación de reglas flightPATH más complejas.