cancelar
Mostrar resultados para 
Pesquisar em vez de 
Queria dizer: 

Problemas comuns envolvendo interações entre WAAS, WCCP e Dispositivos de Segurança

 

Introdução

Como é sabido, o WAAS modifica informações Camada 4 (Layer 4) dos pacotes que otimiza. Usualmente, dispositivos de segurança não "gostam" quando um dispositivo no caminho adiciona/modifica os campos dos pacotes e, por isso, alguns problemas podem surgir quando uma modificaçÃo é detectada.

WCCP também pode criar alguns problemas, já que ele encapsula parte da comunicação em GRE ou quando o dispositivo começa a fazer "spoofing" das respostas "replies" dos servidores reais.

Vamos apresentar neste documento, alguns dos problemas mais comunse como podem ser resolvidos.

 

 

Tráfego otimizado do WAAS passando através de um ASA/FWSM

 

Definição do problema

 

É comum ter o tráfego otimizado de um WAE tendo que passar através de um Firewall, como a seguir:

 

Firewall.jpg

 

Como comentado antes, o WAE modifica o cabeçalho TCP do pacote e duas dessas mudanças serão detectadas pelo Firewall:

 

1. WAE adiciona "TCP option 0x21" ao pacote

 

Por padrão, o firewall vai remover de um pacote todos os "TCP options" não conhecidos. Assim, o "WAAS TCP option 0x21" será removido do pacote. Isso irá impedir que aconteça o "auto discovery" dos WAAS e, consequentemente, impedir a otimização do tráfego.

 

2. WAE incrementa o "TCP sequence number" do "3 Way Handshake ACK" em 2Gb

 

Uma vez que o WAE Edge envia o ACK do "3 Way Handshake" de uma conexão otimizada, ele incrementa o número da conexão TCP em 2Gb para que seja possível diferenciar os pacotes que foram otimizados dos que não foram. Quando o pacote chega ao Firewall, este detecta que o pacote está fora da janela TCP permitida e descarta o pacote. O comando "show asp drop" no Firewall mostrará o valor do contador "TCP packet SEQ past window" incrementando.

 

Solução para versões até ASA 7.2(2) ou FWSM 3.1(11)

Permitir "TCP option 0x21"

 

Primeiramente, será necessária a criação de uma política ("policy map") que permitirá que "TCP option 0x21" passe pelo Firewall intacta:

 

Permitindo "option 0x21"

access-list All-TCP extended permit tcp any any
!
class-map Match-All-TCP
    match access-list All-TCP
!
tcp-map Allow21
    tcp-options range 33 33 allow
!
policy-map global_policy
    class
Match-All-TCP
        set connection advanced-options Allow21
!
service-policy global_policy global

 

Permitir saltos do "TCP sequence number"

 

Agora, quanto ao salto no "TCP sequence number", será necessário desabilitar a randomização do mesmo no Firewall, para que este não o modifique. Consequentemente, também será necessário desabilitar o "TCP state checking" para o tráfego que é otimizad:

 

Permitindo saltos do "TCP sequence number"

static (inside,outside) X.X.X.X X.X.X.X netmask Z.Z.Z.Z norandseq nailed
static (outside,inside) Y.Y.Y.Y Y.Y.Y.Y netmask Z.Z.Z.Z norandseq nailed
!
failover timeout -1

 

Por estranho que pareça, o comando "failover timeout" é necessário para que o parâmetro "nailed"

tome efeito no comando de nat "static".

 

Como pode-se notar, desabilitando completamente o "TCP state checking" parar todo o tráfego otimizado desafia o propósito de um Firewall e é uma medida um tanto drástica. Assim, uma melhoria foi implementada nas versões de software mais recentes.

 

Solução para versões a partir do ASA 7.2(3) ou FWSM 3.2(1)

"WAAS inspection"

 

Para tornar a solução um pouco mais amigável e menos impactante (e conflitante), um novo recurso foi introduzido: "WAAS inspaction" ou inspeção do tráfego dos WAAS.

Se habilitado no Firewall, este automaticamente permite o tráfego otimizado pelo WAAS passar pelo Firewall.

 

Habilitando "WAAS inspection"

policy-map global_policy
    class inspection_default
        inspect waas

 

Para referência, o "release notes" das versões em que este recurso foi introduzido:ASA 7.2(3) FWSM 3.2(1)

 

 

Tráfego otimizado do WAAS passando por um túnel "GRE over IPSEC" or "DMVPN"

 

Definição do problema

 

Quando o tráfego otimizado é enviado para a WAN, espera-se que o mesmo seja encriptado e chega-se a uma topologia como a seguinte:

 

GRE.jpg

 

Nestes casos, como o valor padrão de MSS, o overhead da otimização do WAAS e da criptografia pode causar a fragmentação do pacote IP e pode levar a 2 tipos de problemas diferentes:

 

1. Pacotes com o "DF bit" ativado.

 

Quando um pacote está configurado para fragmentação e tem o "DF bit" ativado, o equipamento que deveria fragmentá-lo vai descartá-lo e enviar uma mensagem ICMP “fragmentation needed and DF bit set” de volta para a origem ("Type 3 Code 4").

O problema surge pois a mensagem ICMP não será redirecionada via WCCP e, consequentemente, o WAE Edge nunca tomará conhecimento de que o pacote foi descartado e simplesmente fará uma restransmissão quando terminar o período de "timeout"

 

2.) Pacotes fragmentados

 

Mesmo quando o pacote não possui o "DF bit" ativado, poderá causar problemas, mas dessa vez no WAE Core. Como o WCCP redirecionará apenas pacotes com cabeçalho TCP, somente o primeiro fragmento será redirecionado e os outros sofrerão "bypass", já que não possuem cabeçalho TCP. Isso fará com que o WAE perca partes da comunicação e impedirá que o tráfego seja otimizado corretamente.

 

Solução

Reduzir o MSS das conexões

 

Existem dois comandos no WAE que o farão diminuir o MSS das conexões passando por ele. Baseado na rede e no overhead que será adicionado ao pacote, pode-se ajustar este valor para evitar que fragmentações ocorram. Você pode ajustar o MSS tanto no lado da WAN:

 

tfo tcp optimized-mss <value>

 

como no lado da LAN:

 

tfo tcp original-mss <value>

 

Uma vez que estes valores sejam reduzidos, pode-se evitar que fragmentações ocorram.

 

Para referência, estes são as referências para estes comandos: tfo tcp optimized-mss tfo tcp original-mss

 

 

Tráfego otimizado do WAAS passando por um IPS

 

Definição do problema

"TCP option 0x21" e salto do "TCP sequence number"

 

Quando se configura a rede WAAS, pode ser necessário que o tráfego passe através de um IPS operando em modo "inline" com a seguir:

 

IPS.jpg

 

Como no caso do Firewall, um IPS em modo "inline" executará algumas verificações na informação da camada 4 ("layer 4"). Também como um Firewall, o IPS vai remover o "TCP option 0x21", evitando o "TFO auto discovery" e vai reportar a mudança feita pelo WAE no "TCP sequence number". O IPS também pode reportar alguns ataques falsos positivos, disparados pelos arquivos de serviços tratados pelo CIFS AO.

 

Solução

 

1. Mudar o modo do Sensor Virtual para Asimétrico ("Virtual Sensor mode Asymmetric")

 

Por padrão, a inspeção TCP do Sensor Virtual está configurada para modo "Strict" ("Virtual Sensor TCP inspection mode Strict") para evitar que ataques passem pelo IPS ao enviar pacotes fora de ordem. Por causa da mudança no número de sequência, podem haver problemas com os pacotes otimizados pelo WAAS. Se você configurar o modo Asimétrico, o IPS não irá normalizar o "TCP sequence number".

 

Para mudar para o modo Asimétrico, utilizando o IDM:

 

- "Configuration > Policies > IPS Policies"

- Selecione o sensor virtual que irá inspecionar o tráfego do WAE e clique em "Edit > Advanced Options"

- Mude o "Normalizer Mode" para  "Asymmetric Mode Protection"

 

Asymmetric.jpg

 

- Clique "Ok > Apply"

- Faça um reboot do sensor

 

Para realizar a mudança via CLI:

 

Changing normalizer mode via CLI

ips# conf t
ips(config)# service analysis-engine
ips(config-ana)# virtual-sensor vs0
ips(config-ana-vir)# inline-TCP-evasion-protection-mode asymmetric
ips(config-ana-vir)# exit
ips(config-ana)# exit
Apply Changes?[yes]: yes
Warning: Change of TCP evasion protection mode will not take effect until restart.
ips# reset

 

 

2. Desabilitar assinaturas que disparariam com o tráfego acelerado do WAAS

 

Existem várias assinatura que é necessário desabilitar para que se possa ter o tráfego do WAAS passando por um IPS. Caso isso não seja feito, haverão alarmes como o seguinte, que dispararão continuamente:

 

evIdsAlert: eventId=1243171268831920721 severity=low vendor=Cisco
   originator:
     hostId: IPS
     appName: sensorApp
     appInstanceId: 6631
   time: 2009/09/17 09:08:13 2009/09/17 12:08:13 GMT+03:00
   signature: description=TCP Option Other id=1306 created=20050304
type=anomaly version=S272
     subsigId: 0
     sigDetails: TCP Option Other Detected
     marsCategory: Info/Misc
   interfaceGroup: vs0
   vlan: 0
   participants:
     attacker:
       addr: locality=OUT X.X.X.X
       port: 0
     target:
       addr: locality=OUT 0.0.0.0
       port: 0
       os: idSource=unknown relevance=unknown type=unknown
   summary: final=true initialAlert=1243171268831920576
summaryType=Regular 3
   alertDetails: Regular Summary: 3 events this interval ;
   riskRatingValue: targetValueRating=medium 50
   threatRatingValue: 50
   interface: ge1_1
   protocol: tcp

 

Estas são as assinaturas que removem os "TCP options" quando passam através do IPS. Existem outras que irão disparar devido à mudança do "sequence number". Segue uma lista das assinaturas que devem ser desabilitadas:

 

Sig ID
Subsig ID
NameDescription

13060TCP Option OtherHere
133012TCP Drop - Segment Out Of OrderHere
133017TCP Drop - Segment out state orderHere
133018TCP Drop - Segment out of windowHere
133019TCP Drop - TCP timestamp option detected when not expectedHere
30300TCP SYN Host SweepHere

 

Se o CIFS AO está sendo utilizado, é interessante desabilitar a assintarua 5581/0

SMB Remote Srvsvc Service Access Attempt , pois ela também pode ser disparada.

 

 

WCCP através de um ASA

 

Definição do problema

 

Caso se esteja implementando um cache/filtro de web, o mesmo deve ser localizado em uma DMZ, como a seguir:

 

CE.jpg


Este cenário pode gerar dois problemas:

 

1. "Reverse path forwarding" descartando "spoofed traffic" do cache

 

Se você tem "reverse path forwarding" habilitado nas interfaces, o Firewall vai comparar o IP de origem dos pacotes recebidos com a tabela de roteamento. Case ele roteasse os pacotes destinado a esse IP pela interface por onde o mesmo foi recebido, ele descarta esse pacote. Se o dispositivo de cache que faz "spoofing" dos sites web responde desde a DMZ, o ASA vai descartar essa resposta ("reply") pois está esperando receber tráfego deste IP na interface "outside" e não na DMZ.

 

2. Pacotes WCCP encapsulados em GRE redirecionados sem retorno encapsulado em GRE ("GRE return")

 

Se o tráfego do roteador para o dispositivo de cache estiver encapsulado em GRE e o tráfego de retorno não estiver, o ASA descartará o SYN/ACK da sessão por não ter visto o SYN inicial da sessão passando por ele.

 

Solução

 

1. Desabilitar "reverse path forwarding"

 

Para prevenir que "uRPF" descarte o tráfego, simplesmente desabilite este recurso na interface à qual o dispositivo de cache está conectado. Via CLI:

 

asa(config)# no ip verify reverse-path interface dmz

 

Para realizar o mesmo, utilizando o ASDM: "Configuration > Firewall > Advanced > Anti-Spoofing" e ajuste o valor para "False" para a interface DMZ.

 

2. Desabilitar "TCP state check"

 

Para evitar que o ASA descarte o SYN/ACK que receber, é preciso que o Firewall faça um "bypass" do "TCP state checking". Se o ASA estiver rodando uma versão anterior à 8.2(1) ou FWSM anterior à 3.2(1) será necessário implementar a mesma solução baseado em NAT estático, como descrito no primeiro tópico.

Se estiverem rodando às versões citadas acima ou outra mais recente, pode-se utiliar a opção "tcp-state-bypass" que foi adicionada à MPF ("Modular Policy Framework"):

 

Desabilitando "TCP state check" com MPF

access-list tcp-bypass permit tcp any any
!
class−map tcp-bypass
match access−list tcp-bypass
!
policy−map tcp-bypass_policy
    class bypass-traffic
        set connection advanced−options tcp−state−bypass
!
service−policy tcp_bypass_policy DMZ

 

Para fazer o mesmo utilizando ASDM: "Configuration > Firewall  > Service Policy Rules" e adicione uma nova política, atrelada à interface à qual o dispositivo de cache está conectado.

Nesta política, ir em "Rule Actions > Advanced options"  e habilitar "state bypass":

 

Bypass.jpg

 

 

Nestas situações, pode ser conveniente habilitar WCCP diretamente no ASA. Vale lembrar que, desta

forma, os usuários e dispositivos de cache precisam estar conectados ao ASA pela mesma interface,

e não por interfaces diferentes.

 

Informações relacionadas:

 

Troubleshooting Prepositioning on WAAS 4.1.1 and above

GRE Redirection in WCCP Creates new tunnel interfaces

 

Virtual Sensor TCP inspection mode is set to StrictMode""
1019
Apresentações
5
Útil
0
Comentários