- Introdução
- Tráfego otimizado do WAAS passando através de um ASA/FWSM
- Definição do problema
- Solução para versões até ASA 7.2(2) ou FWSM 3.1(11)
- Solução para versões a partir do ASA 7.2(3) ou FWSM 3.2(1)
- Tráfego otimizado do WAAS passando por um túnel "GRE over IPSEC" or "DMVPN"
- Definição do problema
- Solução
- Tráfego otimizado do WAAS passando por um IPS
- Definição do problema
- Solução
- WCCP através de um ASA
- Definição do problema
- Solução
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:
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:
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:
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"
- 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
| 1306 | 0 | TCP Option Other | Here |
| 1330 | 12 | TCP Drop - Segment Out Of Order | Here |
| 1330 | 17 | TCP Drop - Segment out state order | Here |
| 1330 | 18 | TCP Drop - Segment out of window | Here |
| 1330 | 19 | TCP Drop - TCP timestamp option detected when not expected | Here |
| 3030 | 0 | TCP SYN Host Sweep | Here |
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:
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":
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