Arquivo

Archive for the ‘TMG’ Category

Não é possível acessar um site HTTPS específico – TLS Encrypted Alert – illegal_parameter(47)

11 de fevereiro de 2012 Deixe um comentário

Problema
=================================

– Não é possível acessar o site https://www.exemplo.com.br através do TMG Server.

Resolução
=================================

– Quando tentamos realizar o acesso ao site através do TMG, o site não era carregado. A página ficava em branco.

– Como de costume, o cliente informou que se o acesso fosse realizado de outra máquina sem passar pelo TMG, o problema não ocorria.

– No log do TMG, filtramos pelo IP do cliente e não foi possível encontrar nada relevante.

– Coletamos o Netmon na máquina cliente que estava realizando o acesso. Como podemos ver abaixo, o SSL handshake não está sendo completado por isso a página não é carregada:

1715 2:42:52 PM 1/27/2012 55.7602103 192.168.0.134      201.XXX.XXX.XXX TCP TCP:Flags=……S., SrcPort=1099, DstPort=HTTPS(443),
1717 2:42:52 PM 1/27/2012 55.8539603 201.XXX.XXX.XXX 192.168.0.134 TCP TCP:Flags=…A..S., SrcPort=HTTPS(443),
1718 2:42:52 PM 1/27/2012 55.8539603 192.168.0.134      201.XXX.XXX.XXX TCP TCP:Flags=…A…., SrcPort=1099, DstPort=HTTPS(443),
1719 2:42:52 PM 1/27/2012 55.8539603 192.168.0.134 201.XXX.XXX.XXX TLS TLS:TLS Rec Layer-1 HandShake: Client Hello
1728 2:42:52 PM 1/27/2012 56.1820853 201.XXX.XXX.XXX 192.168.0.134 TLS TLS:TLS Rec Layer-1 Encrypted Alert
1731 2:42:52 PM 1/27/2012 56.1977103 201.XXX.XXX.XXX 192.168.0.134 TLS TLS:TLS Rec Layer-1 Encrypted Alert

– Se expandirmos o pacote 1728 conseguimos ver mais detalhes do erro:

Frame: Number = 1728, Captured Frame Length = 61, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-1F-D0-F3-63-56],SourceAddress:[00-1B-21-9E-A7-27]
+ Ipv4: Src = 201.16.234.41, Dest = 192.168.0.3, Next Protocol = TCP, Packet ID = 65289, Total IP Length = 47
+ Tcp: Flags=…AP…, SrcPort=HTTPS(443), DstPort=1099, PayloadLen=7, Seq=1745586695 – 1745586702, Ack=2332138847, Win=49368 (scale factor 0x0) = 49368
TLSSSLData: Transport Layer Security (TLS) Payload Data
– TLS: TLS Rec Layer-1 Encrypted Alert
– TlsRecordLayer: TLS Rec Layer-1 Encrypted Alert
ContentType: Encrypted Alert
– Version: TLS 1.0
Major: 3 (0x3)
Minor: 1 (0x1)
Length: 2 (0x2)
EncryptedData: Binary Large Object (2 Bytes)

– Abaixo temos os dados do TLS handshake em Hexa. (Não está encriptado ainda, pois o SSL handshake ainda não foi concluído.)

00 1F D0 F3 63 56 00 1B 21 9E A7 27 08 00 45 00 00 2F FF 09 40 00 33 06 D4 D9 C9 10 EA 29 C0 A8 00 03 01 BB 04 4B 68 0B 8A 07 8B 01 9D 5F 50 18 C0 D8 13 88 00 00 15 03 01 00 02 02 2F

– Os 2 últimos Bytes dos dados em Hexa, representam o Alerta.
– Convertendo o 2F em Decimal temos 47.

– Se abrirmos a RFC do TLS 1.0 e procurarmos por AlertDescription vamos encontrar a tabela a seguir:
http://www.ietf.org/rfc/rfc2246.txt

unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51)

– O acesso está falhando, pois o Web Server não está reconhecendo algum parâmetro enviado pelo cliente, e retorna a mensagem de illegal_parameter(47).

– Após pesquisar sobre esse alerta, encontrei o KB http://support.microsoft.com/kb/980436
– Esse KB é para corrigir uma vulnerabilidade do protocolo TLS. Isso NÃO é um problema do Windows, e sim do TLS. E TODOS os fabricantes já disponibilizaram uma correção para isso como pode ser visto na lista abaixo:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555

– Ao instalar esse KB na máquina cliente, quando a máquina faz uma requisição TLS, no primeiro pacote enviado, que é o “ClientHello”, ela envia o parâmetro Transport Layer Security (TLS) Renegotiation Indication Extension. Muitos servidores que não tem essas atualizações não conseguem interpretar esse tipo de requisição e retornam essa mensagem de Encrypted Alert fazendo com que a conexão se encerre.

WORKAROUND:
=============================

– Para contornar isso seguimos o procedimento do KB http://support.microsoft.com/kb/980436 e configuramos a máquina cliente para que ela não envie o parâmetro “Transport Layer Security (TLS) Renegotiation Indication Extension”. Isso é um Workaround, já que o real problema é o servidor não suportar essa extensão do TLS e como o WebServer roda em Linux, eles não pretendem instalar a atualização. rs

Obs: Perguntei para o cliente como que ele fez o acesso sem passar pelo TMG e tinha funcionado. Ele respondeu que quando estava acessando sem passar pelo TMG, estava usando uma máquina cliente em Linux. Como essa máquina também não tinha a atualização de segurança do TLS, o acesso ocorria normalmente.

– Esse é só mais um caso em que pudemos constatar que muitos dos administradores Linux não tem o hábito de instalar atualizações de segurança, e nesse caso está causando incompatibilidades com outros sistemas. Sem contar a brecha de segurança do site e para o cliente.

– E mais uma vez, a culpa não era do ISA/TMG. 🙂

TMG – User Activity Report – Error: Subreport Could not be shown

15 de setembro de 2011 3 comentários

A Mensagem de erro abaixo foi constatado como sendo um problema na parte de User Activity Report do Forefront TMG.

Esse erro será corrigido no Service Pack 2 ( SP2 ) do TMG que será lançado em breve.

Caso você esteja com esse erro e tenha urgencia em resolve-lo, você pode abrir um chamado na Microsoft pois já existe um correção que pode ser disponibilizada.

Abraços

Renato Marson Pagan

Troubleshooting: ISA / TMG Instável, congelando, intermitente

Nos últimos meses tivemos muitos chamados referentes a problemas de performance no TMG.

Casos em que o TMG congelava, parava de responder por alguns instantes entre outros.

Abaixo seguem algumas recomendações que normalmente resolvem esses problemas e que podem ser aplicadas em todos os ambientes para prevenir que esse tipo de problema ocorra no futuro.

——————-

  • Evitar ao máximo a utilização de regras com a opção All Outbound Traffic + Autenticação de usuário.
  • Evitar ao máximo a utilização de regras com a opção All Outbound Traffic + Domain Name Set

    Em ambos os casos, o TMG depende de outros servidores para validar as regras.

    No primeiro caso, toda requisição que chega ao TMG, ele precisa contatar o DC para autenticar o usuário, mesmo que esse trafego não seja necessário.

    No segundo caso, o TMG depende do servidor DNS para fazer uma consulta reversa e assim comparar com o Domain Name Set

    Por isso é altamente recomendado que regras que contenham autenticação de usuários ou Domain Name Set NÃO sejam utilizadas com All Outbound Traffic.

    O link abaixo explica bem esse comportamento.

    http://blogs.technet.com/b/isablog/archive/2009/01/12/isa-server-2006-stops-answering-requests.aspx

—————-

———————–

————————

  • Verificar as configurações de rede.

    Deixar DNS configurado somente na placa de rede interna.

    Verificar Binding Order: Rede interna sempre no topo.

    Sempre verificar que as placas de rede estão utilizando os drivers mais atuais possiveis.

————————-

————————–

  • Caso o TMG continue travando e apresentando problemas de performance será necessário coletar alguns logs para serem analisados:

    Configurar Perfmon com os contadores abaixo:

ISA Server Firewall Packet Engine/*

ISA Server Firewall Service/*

ISA Server Web Proxy/*

Cache/*

Logical Disk/*

Memory/*

Netlogon/*

Network Interface/*

Objects/*

Paging File/*

Physical Disks/*

Process/*

Processor/*

Redirector/*

Server/*

Server Work Queues/*

System/*


Ativar o modo Debugging do Netlogon

http://support.microsoft.com/kb/109626

Uma boa maneira de iniciar a análise do Perfmon é utilizando o PAL:

http://pal.codeplex.com/

————————-

[]’s

Renato Marson Pagan

Categorias:TMG Tags:, , , ,

Problemas ao acessar HTTP e HTTPS em uma VPN Site to Site

12 de julho de 2011 1 comentário

Problema
=============================

– Cliente tem uma VPN site to site e precisa acessar o webserver localizado no site remoto mas não está sendo possivel.

Ambiente
==================================

– VPN IPSEC Site to Site entre um TMG e um CISCO ASA.

– Nas configurações do TMG em Network Rules o relacionamento entre as redes da VPN era Route.

Resolução
=============================

– Nesse caso, só não era possível fazer o acesso HTTP ao Webserver.

– Conseguiamos nos conectar no webserver através de RDP e era possível pingar o servidor. Somente o acesso HTTP recebia Timeout.

– Nos logs do TMG tínhamos a mensagem:

Log type: Web Proxy (Forward)
Status: 10060 A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

– Estavamos realizando os testes a partir da máquina cliente 192.168.0.10. Ao monitorar o CISCO os pacotes HTTP estavam chegando com o IP 200.200.200.1 que é o IP externo do TMG.

– Como a relação entre as duas redes é de Roteamento, isso significa que o trafego HTTP estava sofrendo NAT e isso não é recomendado em uma VPN IPSEC. O trafego deveria chegar com o IP do cliente.

– Isso ocorre pois quando o trafego HTTP passa pelo TMG ele é tratado pelo Web Proxy Filter e esse filtro sempre utiliza NAT. Mesmo não marcando o endereço de proxy no navegador (Navegando por SecureNAT) o problema ocorre, pois é tratado como transparente Proxy pelo Web Proxy Filter.

– Para solucionar esse problema precisamos de um “workaround” para que o trafego HTTP entre as redes VPN não seja tratado pelo Web Proxy Filter:

– Criar um novo protocolo “HTTP Sem filtro” com a porta 80 outbound e desabilitar o Web Proxy Filter.

– Criar uma nova access rule com Source = “Internal” e Destination = “Rede VPN” utilizando esse novo protocolo criado.

– Criar uma acess rule com All outbound traffic except selected e selecionar o protocol HTTP como exceção – From “Internal” to “Rede VPN”. Colocar essa regra abaixo da regra liberando o trafego “HTTP sem filtro”.

– Outro Workaround é desabilitar o filtro Web Proxy Filter do protocolo HTTP, mas nesse caso teríamos várias desvantagens. Todo o trafego HTTP não seria tratado pelo WebProxy Filter e a funcionalidade de Cache do TMG não funcionaria.

———————————————————————————————-

Renato Marson Pagan

TMG – NLB – Bi Directional Affinity ( BDA ) – Afinidade Bi Direcional

Considere o Ambiente abaixo com um Array com 2 Servidores TMG e com NLB configurado somente para a rede interna.

Ambiente
—————————————-

Nesse caso, o cliente estava utilizando os 2 nós do array para publicar um único servidor SMTP na rede interna.

O Servidor SMTP estava publicado na internet com os IPs 200.200.200.1 no TMG01 e 200.200.200.2 no TMG02.

O balanceamento havia sido feito no DNS, configurando o MX para os IPs 200.200.200.1 e 200.200.200.2 conforme descrito no link abaixo:

http://www.zytrax.com/books/dns/ch9/rr.html#mail

Problema:
———————————–

– Foi publicado o servidor SMTP com uma regra recebendo os dois IPs válidos, um em cada servidor TMG, quando tentávamos o aceso por um ip funcionava corretamente, quando tentávamos refazer o mesmo teste usando o outro ip publicado ele não aceitava, ficava aguardando e depois apresentava o com o erro abaixo no log do servidor TMG:

Failed Connection Attempt
Log type: Firewall servisse
Status: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

– Não era possível se conectar no servidor SMTP utilizando-se os 2 IPs externos. Ou funcionava um ou outro.

Resolução:
—————————————-

– Olhando a regra de publicação, na aba “TO” a opção “Requests appear to come from the original client” estava selecionada.

– Alteramos essa opção para “Requests appear to come from the ISA Server computer”.

– Após essa alteração, conseguimos nos conectar com sucesso em ambos os IPs externos.

– Com isso, aparentemente o caso havia sido resolvido.
– Estavamos conseguindo conectar no servidor SMTP utilizando os dois IPs, passando pelos 2 TMGs. Mas o servidor que estava sendo publicado era um SMTP Server. Os servidores SMTP precisam saber o IP de origem da conexão para fazer consulta do DNS Reverso .
– Por esse motivo, não seria possível manter a opção “Requests appear to come from the ISA Server computer”.

– Quando a opção “Requests appear to come from the ISA Server computer” está marcada, o TMG envia a requisição para o servidor SMTP com o IP dele. Com isso, quando o servidor SMTP responde para o VIP, o mecanismo do NLB sabe identificar de qual nó o trafego veio e envia a resposta para o nó correto.

– A opção “Requests appear to come from the original client” não funciona quando temos NLB em uma única interface do TMG. Abaixo segue a explicação:

– Quando uma requisição é realizada por um cliente externo, um dos nós do TMG irá se encarregar de encaminhar essa requisição para o servidor SMTP na rede interna. Essa requisição chega ao servidor SMTP com o IP do cliente que fez a requisição.
– Quando o Servidor SMTP responde essa requisição, ele envia para o gateway cadastrado na placa de rede (nesse caso é o VIP do NLB).
– O problema ocorre quando a requisição externa é feita para o TMG01 e na resposta do SMTP Server, o NLB (que não sabe de qual nó a conexão foi iniciada pois o endereço de destino é externo) encaminha esse pacote para o TMG02. Isso faz com que a conexão seja quebrada.

– Para resolver esse problema, precisamos que as conexões em ambas as direções passem pelo mesmo TMG. A única maneira de fazer isso, é configurar as placas externas do TMG em NLB.

– Com o NLB configurado na placa Interna e externa, temos a afinidade Bi-Direcional.

– Essa afinidade bi-direcional, garante que a requisição e a resposta passem pelo mesmo nó do array fazendo que seja possível se conectar por ambos os IPs externos.

———————————————————————–

Nos artigos abaixo, é muito bem descrito o funcionamento do NLB BDA.

http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx

http://www.isaserver.org/articles/2004nlbbdarevisted.html

———————————————————————————————-

Renato Marson Pagan