Exchange 2007 CAS - Vantagens do ISA Server sobre a porta de encaminhamento 443

Question

Estou trabalhando na implantação do Exchange 2007 em um ambiente existente do Exchange 2003. A Microsoft não oferece suporte à colocação de um servidor de acesso para cliente (CAS) do Exchange 2007 em uma rede de perímetro / DMZ. Em vez disso, a Microsoft sugere colocar um ISA Server na rede de perímetro / DMZ e usá-lo para reverter as solicitações de proxy para o servidor CAS.

Qual é a vantagem de usar o servidor ISA como um proxy reverso comparado ao encaminhamento da porta 443 da rede externa através do perímetro / DMZ para o servidor CAS na rede interna? Terei problemas de certificado SSL se eu encaminhar a porta? Existem outras portas que precisam de encaminhamento?

Atualização: achei as duas vantagens a seguir aqui :

When you publish an application through ISA Server, you are protecting the server from direct external access because the name and IP address of the server are not accessible to the user. The user accesses the ISA Server computer, which then forwards the request to the server according to the conditions of the server publishing rule.

SSL bridging protects against attacks that are hidden in SSL-encrypted connections. For SSL-enabled Web applications, after receiving the client's request, ISA Server decrypts it, inspects it, and terminates the SSL connection with the client computer. The Web publishing rules determine how ISA Server communicates the request for the object to the published Web server. If the secure Web publishing rule is configured to forward the request using Secure HTTP (HTTPS), ISA Server initiates a new SSL connection with the published server. Because the ISA Server computer is now an SSL client, it requires that the published Web server responds with a server-side certificate.

Adicionar uma segunda parte à pergunta é justificativa para comprar um segundo servidor, licenciamento, configuração, solução de problemas etc. Como você fez isso em seu ambiente, especialmente em ambientes pequenos (< 200 usuários)?

    

Answer 1

A principal vantagem em usar o ISA Server como um proxy reverso é a segurança, mas é claro que faz muito mais sentido se você tiver mais de um aplicativo para publicar; Se você só precisa disponibilizar seu (s) servidor (es) CAS do Exchange externamente, talvez comprar, implementar e gerenciar o ISA seja um pouco exagerado.

O uso do ISA, em vez de encaminhar claramente a porta TCP 443, oferece as seguintes vantagens:

• Pré-autenticação . Os usuários podem ser autenticados pelo próprio ISA Server e, em seguida, a solicitação será encaminhada ao servidor real publicado somente se essa autenticação suceder; Isso impede que usuários não autenticados tentem adulterar seu aplicativo da Web, economizando para você. de possíveis erros no logon do aplicativo.
• Filtragem HTTP . Conexões HTTPS padrão fluem através de um firewall de rede sem serem analisadas, porque o tráfego é, obviamente, criptografado; com o ISA, as conexões HTTPS são feitas a partir do cliente para o proxy ISA e, em seguida, reabertas pelo ISA ao servidor da Web, permitindo que o ISA inspecione e limpe o tráfego HTTP real; isso não permite solicitações "estranhas" para seus aplicativos publicados, evitando muitos bugs de aplicativos (estouro de buffer, etc.).
• Filtragem de URLs . Se você abrir a porta TCP 80 e / ou 443 em um servidor da Web interno, um cliente poderá solicitar ao servidor da Web qualquer coisa desejada (domínio, site, caminho, arquivo etc.); O ISA Server pode ser configurado para aceitar apenas determinadas URLs, portanto, se você tiver um servidor da Web que hospeda vários sites ou algum site somente interno ou alguma área de armazenamento privada, etc., pode ter certeza de que apenas solicitações como " link "pode alcançá-lo.
• Redirecionamento HTTPS . Ok, isso não é um grande problema, mas, falando de URLs, quantos usuários esquecem de colocar esse "s" depois de "HTTP"? Você pode redirecionar automaticamente o tráfego HTTP para HTTPS com o ISA.
• Balanceamento de carga . Se você tiver mais de um servidor da Web para o mesmo aplicativo, o ISA Server poderá balancear a carga como um único site publicado, sem a necessidade de balanceadores de carga de rede de hardware ou software; esse balanceamento de carga também acontece no nível HTTP, e não no TCP, para que possa gerenciar melhor as sessões do cliente.
• Todos os outros recursos do ISA Server . Claro. Mas não os negligencie. Você pode configurar suas regras de publicação na Web para permitir somente determinados usuários, somente em determinados momentos, somente a partir de determinados intervalos de IP, etc .; você também pode publicar muitos servidores web internos em um único endereço IP externo, etc .; Há muitas coisas que você pode fazer com o ISA depois de implementá-lo, além de publicar um servidor CAS do Exchange.

Answer 2

Eu parei de usar o ISA um pouco depois da edição de 2004. Embora a funcionalidade e a "facilidade" da integração com os produtos MS sejam uma vantagem, um firewall de hardware existente, se configurado corretamente, pode ser tão seguro quanto.

Eu descobri que o ISA no mix acabou de adicionar outra camada de complexidade e realmente introduziu um pouco de lentidão também.

Portanto, minhas recomendações é usar um IP mapeado (MIP) para o servidor CAS para apenas as portas necessárias (80/443, etc.) para as funções.

O argumento que ouvi é que ter o ISA lá no meio impede as pessoas de tentarem invadir seu servidor CAS, mas se o seu servidor CAS estiver bem configurado e especialmente se você utilizar o ACS para Windows no servidor CAS afinal de contas está configurado e funcionando, então você realmente não terá mais segurança para se preocupar se você tivesse ISA no meio.

Agora ... Dr. Shinder e outros irão discordar strongmente e pedir-lhe para colocar uma caixa ISA, mas o que eu acho engraçado é que a maioria das pessoas fora de "Administradores do Windows" que são especialistas em rede / firewall simplesmente não as usam ... que me diz algo .

    

Answer 3

O ISA é caro para implantar e realmente não faz muito sentido se você for usá-lo apenas para conexões de entrada.

Faz muito sentido armazenar em cache as solicitações de saída de 1000 usuários, especialmente para páginas de alto volume, como Google, MSN, portais, etc. Mas, para entrada, você pode fazer o mesmo por um custo muito menor.

Como TheCleaner mencionou, você pode bloquear seu servidor web / CAS sem problemas, independentemente de ser Windows ou * nix.

É sensato perguntar sobre o SSL. Cada SSL precisará ter seu próprio endereço IP - sendo que seu dispositivo de borda não poderá descriptografar nenhum cabeçalho de host, por isso você precisa mapear qualquer solicitação recebida em seu IP SSL para um endereço IP específico no CAS, para que o CAS saberá qual certificado usar.

Resumo básico: Se você já tem um bom dispositivo de borda, não se preocupe. Se você não fizer isso, algo como pfSense não demorará mais a ser configurado do que o ISA, tem uma pegada muito menor (pode ser feliz executado em uma VM com 128 MB de RAM) e você não precisa licenciar o Windows e pagar uma licença adicional pelo ISA.