Meus colegas da Edgenexus acreditam que, embora os balanceadores de carga F5 LTM sejam extremamente avançados e flexíveis, a dependência do uso de scripts iRules para executar algumas funções básicas leva a uma complexidade desnecessária.
Você só precisa fazer uma busca on-line por F5 iRules para descobrir a dor e a angústia que muitos profissionais de TI têm de enfrentar no processo de criação de iRules funcionais. Embora seja verdade que a expansão da funcionalidade “Local Traffic Policies” nas versões recentes do software da F5 tenha eliminado parte da necessidade de criar iRules para funções comuns de manipulação de cabeçalhos HTTP, muitos usuários ainda estão presos a iRules herdadas na configuração do sistema.
As políticas de tráfego local não parecem permitir a manipulação de dados HTML, embora as políticas de fluxo o façam, elas são um tanto desajeitadas e difíceis de controlar. Por padrão, elas afetam o tráfego em ambas as direções da mesma forma, embora isso geralmente não seja desejável. Isso significa que você deve voltar às iRules para executar funções como a substituição do link do corpo do texto do URL de http:// para https://, que pode ser necessária em conjunto com um redirecionamento de http:// para https, que pode ser executado usando as políticas de tráfego local.
Entre no Edgenexus flightPATH – Gerenciamento de tráfego facilitado
Na Edgenexus, temos orgulho do poder e da simplicidade de configuração de nossa função de manipulação HTTP flightPATH Layer 7.
Se você já é usuário da F5 e utiliza o iRules para manipulação de HTTP ou HTML, ficaríamos muito satisfeitos em ter a oportunidade de fazer uma demonstração do balanceador de carga Edgenexus ALB-X e mostrar como o flightPATH é simples de configurar para realizar algumas funções relativamente complexas. Gostaríamos de ser colocados à prova para ajudar você a traduzir suas funções iRules existentes em regras do flightPATH.
Como exemplo, reproduzimos abaixo uma seleção de F5 iRules com as capturas de tela de configuração de regras flightPATH equivalentes da Edgenexus.
IP de origem Direção do servidor de conteúdo
Aqui está um exemplo de como o F5 iRules pode ser usado para direcionar os usuários de um determinado intervalo de endereços IP para um pool de servidores e os de outro intervalo para outro pool de servidores.
F5:
| Nome: | IP_Choice |
| Definição: | 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:
- Crie uma nova regra flightPATH com o nome IP_Choice_Pool_1 por meio da Web GUI. Adicione uma descrição concisa para que você possa identificar qual é a função que a regra flightPATH está executando.
- Adicione uma nova condição, selecionando Source IP na extensa lista suspensa. Selecione “Does” (Faz) na lista suspensa Sense (Sentido). Uma opção é selecionar Start na lista suspensa Check (como alternativa, você pode usar outras opções, como RegEx, para oferecer mais flexibilidade ao endereço IP ‘Value’). Digite o intervalo de IP inicial na caixa Value (Valor).
- Adicione uma nova ação. Na caixa suspensa Ação, escolha a opção Usar servidor (há também a opção Usar servidor seguro, se necessário). Na caixa Target (Destino), digite o endereço IP e a porta do destino desejado. Normalmente, trata-se de outra interface do Virtual Service para permitir o balanceamento de carga em outro pool de servidores reais.
Redirecionamento de HTTP para HTTPS
Embora a F5 agora tenha uma alternativa ao uso do iRules para executar o redirecionamento de HTTP para HTTPs, há muitos casos em que as pessoas ainda estão usando o iRules para essa função. O iRules também permite uma maior personalização dos parâmetros de redirecionamento.
F5:
| Nome: | Redirecionamento de HTTP_HTTPs |
| Definição: | Quando HTTP_REQUEST { HTTP::redirect “https://[HTTP::host][HTTP::uri]” } |
Edgenexus:
- Crie uma nova regra flightPATH com o nome Redirecionar HTTP para HTTPS por meio da GUI da Web. Adicione uma descrição concisa para que você possa identificar qual é a função que a regra flightPATH está executando.
- Na maioria dos aplicativos, o requisito para realizar o redirecionamento de HTTP para HTTPS precisa ser executado em todo o tráfego que atinge o serviço HTTP. Nesse caso, nenhuma regra de condição precisa ser criada. Há uma grande flexibilidade para criar regras de condição se a regra flightPATH afetar apenas determinado tráfego.
- Adicione uma nova ação escolhendo Redirect 302 na caixa suspensa Action (Redirect 301 também está disponível). O Edgenexus ALB-X cria automaticamente variáveis para determinados parâmetros-chave do tráfego processado pelo ALB-X, o que inclui o host, o caminho e a string de consulta. Na caixa Target (Destino), insira os detalhes do local para onde a solicitação deve ser redirecionada. Nesse caso, preceda a entrada https:// e use as variáveis $host$$path$$$querystring$ para inserir os dados da solicitação http original. Como você pode ver, há flexibilidade aqui para definir um destino completamente diferente, se necessário.
Mascarar números de cartões de crédito
Aqui está um exemplo das complexidades das iRules e da maneira como o F5 lida com a manipulação do corpo HTML.
F5:
| Nome: | Mascaramento do número do cartão de crédito |
| Definição: | quando HTTP_REQUEST { # Impedir que o servidor envie uma resposta compactada # Remover as ofertas de compactação do cliente HTTP::header remove “Accept-Encoding” # Não permita que os dados de resposta sejam divididos em pedaços if { [HTTP::version] eq “1.1” } { # Forçar o downgrade para HTTP 1.0, mas ainda permitir conexões keep-alive. # Como o HTTP 1.1 é “keep-alive” por padrão, e o 1.0 não, # Precisamos garantir que os cabeçalhos reflitam o status keep-alive. # Verificar se essa é uma conexão keep alive se { [HTTP::header is_keepalive] } { # Substitua o valor do cabeçalho da conexão por “Keep-Alive” HTTP::header replace “Connection” “Keep-Alive” } # Definir a versão da solicitação do lado do servidor como 1.0 # Isso força o servidor a responder sem fragmentação HTTP::versão “1.0” } } quando HTTP_RESPONSE { # Verifique apenas as respostas que são do tipo de conteúdo de texto (text/html, text/xml, text/plain etc.). if { [HTTP::header “Content-Type”] starts_with “text/” } { # Obtenha o tamanho do conteúdo para que possamos coletar os dados (a serem processados no evento HTTP_RESPONSE_DATA) # Limitar a coleta a 1Mb (1048576 menos um pouco) – Consulte SOL6578 para obter detalhes se { [HTTP::header exists “Content-Length”] } { se { [HTTP::header “Content-Length”] > 1048000 }{ # Content-Length acima de 1Mb, portanto, colete 1Mb definir content_length 1048000 } else { # Content-Length abaixo de 1Mb, portanto, colete o comprimento real definir content_length [HTTP::header “Content-Length”] } } else { # A resposta não tinha o cabeçalho Content-Length, portanto, use o padrão de 1Mb definir content_length 1048000 } # Não coletar conteúdo se o valor do cabeçalho Content-Length for 0 se { $content_length > 0 } { HTTP::collect $content_length } } } quando HTTP_RESPONSE_DATA { # Encontre TODOS os números de cartão de crédito possíveis em uma única passagem 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 { definir card_start [lindex $card_idx 0] definir card_end [lindex $card_idx 1] set card_len [expr {$card_end – $card_start + 1}] definir card_number [intervalo de strings [HTTP::payload] $card_start $card_end] # Remova o traço ou o espaço se eles existirem e conte as ocorrências em recortes variáveis. Definir recortes [regsub -all {[-]} $número_do_cartão “” número_do_cartão] # Você deve ajustar a variável card_len, mas guardá-la para uso posterior. set new_card_len [expr {$card_len – $cutouts}] set double [expr {$new_card_len & 1}] definir chksum 0 definir isCard inválido # Calcular MOD10 for { set i 0 } { $i < $new_card_len } { incr i } { definir c [string index $card_number $i] Se {($i & 1) == $double} { se {[incr c $c] >= 10} {incr c -9} } incr chksum $c } # Determinar o tipo de cartão switch [string index $card_number 0] { 3 { definir tipo AmericanExpress } 4 { definir tipo Visa } 5 { definir tipo MasterCard } 6 { definir tipo Discover } padrão { definir tipo Desconhecido } } # Se o número do cartão for válido, mascare os números com Xs se { ($chksum % 10) == 0 } { definir isCard valid HTTP::payload replace $card_start $card_len [string repeat “X” $card_len] } # Resultados do registro log local0. “Encontrado $isCard $type CC# $card_number” } } |
Edgenexus:
- Crie uma nova regra flightPATH e forneça uma descrição significativa
- Esse é outro exemplo em que a correspondência de condições pode não ser necessária, pois normalmente você desejaria proteger todas as respostas do servidor. É claro que existe a opção, se você precisar.
- Adicione uma nova “Ação” e escolha “Corpo Substituir Tudo” na opção do menu suspenso. Você pode usar expressões regulares para fazer a correspondência com o texto de destino a ser substituído por essa ação. Use \b(?:\d[ \t-]?){12}\b como o alvo para detectar e substituir os primeiros 12 dígitos dos números de cartão de crédito. No campo Data (Dados), digite xxxx-xxxx-xxxx como o texto de substituição. Isso deixará os últimos 4 dígitos habituais intactos como um identificador.
- Repita o processo acima para outros tipos de dados confidenciais, como números de seguro nacional, usando \b(?:\d[ \t-]?){7}\b substituído por xxx-xxxx e \b(?:\d[ \t-]?){6}\b substituído por xxx.xxx
- Com o uso criterioso de expressões regulares, uma grande variedade de sequências de caracteres pode ser combinada e mascarada simplesmente usando a ação Substituir corpo. Body Replace First (Substituir primeiro corpo) e Body Replace Last (Substituir último corpo) são outras opções de ação que podem ser usadas quando apenas a primeira ou a última instância de uma sequência de caracteres em uma página precisa ser substituída.
Remover possíveis cabeçalhos X que comprometam a segurança
Muitas vezes, é citado como boa prática evitar o fornecimento de informações desnecessárias sobre a infraestrutura do servidor usada para a entrega de um aplicativo, removendo determinados cabeçalhos HTTP que são inseridos por padrão pelo aplicativo ou pela tecnologia do servidor. Quanto mais um hacker souber sobre o sistema que está tentando explorar, mais fácil será. Geralmente, há um intervalo entre a publicação das vulnerabilidades do sistema e a aplicação de patches. É durante esse período que os sistemas estão mais ameaçados e que o processo de ocultar os detalhes da plataforma de fornecimento de aplicativos é mais útil.
Muitas das informações desnecessárias estão contidas nos X-Headers. A iRule a seguir executa uma remoção geral do X-Header que pode não ser desejável.
F5:
| Nome: | Remoção do cabeçalho HTTP X-Server |
| Definição: | quando HTTP_RESPONSE { # Remover todas as instâncias do cabeçalho do servidor HTTP::header remove Servidor # Remova todos os cabeçalhos que começam com x- foreach header_name [HTTP::header names] { Se {[string match -nocase x-* $header_name]}{ HTTP::header remove $header_name } } } |
Edgenexus:
- Crie uma nova regra flightPATH com um nome significativo, por exemplo, Remove HTTP Headers (Remover cabeçalhos HTTP)
- Este é um exemplo de uma regra flightPATH em que provavelmente não será necessária uma correspondência de condições. Há um conjunto abrangente de critérios de seleção disponíveis, se necessário.
- Adicione uma nova ação para “Remover cabeçalho de resposta”; no campo Destino, digite o valor do cabeçalho a ser removido. Adicione uma entrada de ação Remove Response Header para definir cada um dos campos de cabeçalho que você deseja que sejam mascarados nas respostas do servidor. Uma ação geral de remoção de todos os cabeçalhos personalizados com prefixo X poderia, na verdade, ter um efeito prejudicial, portanto, o flightPATH exige que você defina os cabeçalhos específicos que precisam ser removidos.
- Aplique o flightPATH criado a cada um dos serviços em que a ação é necessária.
Aplicação de regras flightPATH a serviços virtuais
O flightPATH é uma ferramenta de manipulação de HTTP muito eficiente, mas simples de usar. Você pode criar uma “biblioteca” de regras flightPATH para executar várias ações no tráfego HTTP à medida que ele atravessa o dispositivo de balanceamento de carga ALB-X. Várias regras flightPATH podem ser aplicadas a um serviço virtual. As regras do flightPATH são processadas na ordem em que são aplicadas ao serviço. Algumas regras de flightPATH encerram o processamento. Você pode usar o recurso de arrastar e soltar para reorganizar a ordem e garantir que todas as ações sejam executadas conforme necessário. A edgeNEXUS pode oferecer serviços profissionais para auxiliar na tradução e criação de regras flightPATH mais complexas.
Você quer saber mais?
Para obter mais informações sobre a manipulação de tráfego da Edgenexus , clique aqui.
Para fazer o download de uma avaliação gratuita do ALB-X , clique aqui.
Gostaríamos de ter a oportunidade de demonstrar a funcionalidade do Edgenexus ALB-X e do flightPATH. Solicite uma demonstração técnica rápida e pessoal aqui.
