Sobre filtros web de terceiros no Forefront TMG ou ISA Server

9 de abril de 2014 Deixe um comentário

Saudações,

Como não é mais segredo para quem me acompanha, comecei dia 25 de fevereiro deste ano como Green Badge Engineer na Microsoft. Durante este ano estarei alocado em clientes Microsoft como Premier Field Engineer cuidando da parte de segurança com suporte a ferramentas como Forefront TMG, AD RMS, AD FS, IIS e a parte de patche management. Com um bom trabalho e uma ajudinha do Papai do Céu, quem sabe não fico em definitivo!

A idéia deste post é mostrar casos que ainda se repetem em clientes que optaram por manter o Forefront TMG por mais algum tempo, fazendo a integração do mesmo com outras ferramentas para a parte de secure web gateway, como Filtro de Conteúdo por exemplo.

Para casos envolvendo o Forefront TMG, é muito dificil que um problema como esses ocorra, salvo pela falta de atualização do plug-in de terceiros e/ou problemas na própria instalação.

No que tange ao ISA Server 2006, é fundamental que a instalação não tenha nenhum tipo de erro e que a última versão do plug-in para ISA esteja instalado. Para maiores detalhes, procure informações com o fabricante do filtro de conteúdo terceiro e veja se a versão que vc usa é a correta.

Normalmente uma instalação danificada do plug-in, ou uma versão mais antiga sem suporte aos novos tipos de requisição e acessos, vai fazer com que o usuário final sinta latência em seus acessos ou até mesmo receba uma mensagem de “access denied” mesmo para sites permitidos pelas políticas.

Dependendo do problema, o plug-in pode também enfileirar requisições até consumir todos os recursos disponíveis do servidor, causando o crash do serviço do ISA ou TMG (mais comum no ISA  Server que, neste caso, divide sua engine no Kernel mode com a do plug-in).

Normalmente o restart do serviço resolve, mas, esse problema, se não tratado, começa a ocorrer com frequência afetando toda massa de usuários e causando os mais variados dissabores. Neste caso, prevenção e busca da solução definitiva é a única saída.

Veja abaixo os erros que podem ocorrer (os log´s abaixo são de uma infra estrutura grande de ISA Server, ainda em uso em um cliente):

Event Type:            Error

Event Source:        Microsoft Firewall

Event Category:    None

Event ID: 14057

Date:                      4/3/2014

Time:                      11:30:17 AM

User:                       N/A

Computer:            

Description:

The Firewall service stopped because an application filter module C:\Program Files\Microsoft ISA Server\w3filter.dll generated an exception code C0000005 in address 6472F7A3 when function CompleteAsyncIO was called. To resolve this error, remove recently installed application filters and restart the service.

No erro acima pode se ver que o filtro do próprio ISA é o primeiro a ser impactado pelo filtro de terceiros. Após a parada no w3filter.dll, ocorre o erro abaixo:

Event Type:            Error

Event Source:        Microsoft Firewall

Event Category:    None

Event ID: 14007

Date:                      4/3/2014

Time:                      11:30:17 AM

User:                       N/A

Computer:            

Description:

A shortage of available memory caused the Firewall service to fail. The ISA Server computer cannot support additional connections for the server. The Event Viewer Data window displays the number of active connections.

O erro acima mostra que o filtro de terceiros foi enfileirando requisições por não conseguir trata-las e consumiu todos os recursos do servidor. Após esse erro, pode ser encontrado outro conforme abaixo:

Event Type:            Error

Event Source:        Microsoft ISA Server 2006

Event Category:    None

Event ID: 1000

Date:                      4/3/2014

Time:                      11:30:20 AM

User:                       N/A

Computer:            

Description:

Faulting application wspsrv.exe, version 5.0.5723.527, stamp 4f7071bd, faulting module w3filter.dll, version 5.0.5723.527, stamp 4f70717d, debug? 0, fault address 0x0003f7a3.

O erro acima mostra o momento em que, influenciado pelo filtro w3filter.dll, o processo do proxy cai.

Caso o problema esteja ocorrendo por erros na própria instalação do plug-in ou por falta de alguma biblioteca da mesma, o erro abaixo ocorre (para quem usa web filter que encaminha para um WebSense Server):

Event Type:            Information

Event Source:        Websense-ISA

Event Category:    None

Event ID: 4096

Date:                      4/3/2014

Time:                      2:46:29 PM

User:                       N/A

Computer:            

Description:

The description for Event ID ( 4096 ) in Source ( Websense-ISA ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Webfilter initialized..

Usar plug-in de web filters de terceiros é totalmente viável, mas, recomendo fortemente  que, se ainda usam ISA Server e entendem que o TMG pode suporta-los por algum tempo, que migrem o mais rápido possível. O uso do ISA Server fica muito limitad a uma plataforma 32 bits que a muito não suporte grandes cargas de acesso.

Caso contrário, analise no mercado a solução de proxy e secure web gateway que vai de encontro a suas necessidades, lembrando que, para publicação de aplicações, o Web Application Proxy do Windows Server 2012 R2 e o Application Request Routing do IIS 8.5 (para publicação de OWA) são opções eficazes e baratas para supir parte daquilo que o Forefront TMG faz em sua estrutura.

Abraços

Uilson

CategoriasNão categorizado

Configurando o Centralized Certificate Store no IIS 8.5 do Windows Server 2012 R2

24 de março de 2014 Deixe um comentário

Saudações,

Hoje quero falar sobre um tema que acho muito importante para quem administra o IIS com aplicações protegidas por certificado digital. Inclusive este foi um dos temas que falei nas minhas palestras sobre Segurança em Redes Microsoft para o projeto Quintas da TI, na série de webcasts dos MTAC´s e no MVP  ShowCast.

Em se falando de proteção SSL, o administrador de um webserver IIS tem que lidar com uma série de procedimentos para configurar uma aplicação com certificado. Vamos tentar entender todos os passos (ou parte deles):

1. Gerar a CSR no IIS e enviar para validação em uma CA externa ou interna (no caso de validação interna, para sites que serão acessados somente pelos usuários da corporação).

2. Após validação, aplicar este certificado através da conclusão da solicitação da CSR no próprio WEB Server

Pouco né?

Mas, imagine que vc tem diversos webserver´s em sua estrutura, sendo que, em muitos casos o mesmo certificado pode ser usado em N servidores da mesma farm ou de farm´s diferentes. Além disso uma série de aplicações podem requerer seu próprio certificado, gerando a necessidade de importar muitos certificados em muitos servidores.

Vc teria que exportar o certificado para um arquivo PFX de forma a importar nos servidores da farm, usando o Snap-in Certificates via MMC, para que o tráfego SSL ocorra sem problemas.

Para os casos de empresas que fazem host de aplicações WEB, entre outras, esse processo pode ser automatizado através da aplicação de políticas que irão replicar estes certificados a um determinado grupo de servidores.

Agora, a partir do Windows Server 2012, este processo ocorre de uma forma mais eficaz, em se tratando de grandes estruturas de web farms.

O IIS, a partir da versão 8, traz a funcionalidade “Centralized Certificate Store”. Com ele vc pode armazenar seus certificados em um file share, sem a necessidade de importar o mesmo para a conta Computer no Sna-In Certificates da máquina. Para que o CCS seja instalado com a role do IIS, é preciso seleciona-lo no momento da instalação.

Dessa forma, a aplicação vai buscar o certificado neste file share, sendo que você só precisa que toda a farm de webserver´s tenha acesso a esta pasta.

Vamos ver o passo a passo dessa configuração:

Para escrever este post, eu montei um laboratório com 1 servidor contendo o AD-DS e o AD-CS (Root CA), outro com o IIS e ainda mais dois servidores com AD-RMS e AD-FS que estão servindo para estudo e aprofundamento nessas tecnologias, além de serem fonte para muitos outros artigos a serem postados aqui.

O domínio responde pelo nome de uilson.net. A aplicação que iremos usar para o CCS (Centralized Certificate Store) responde pela URL www.uilson.net e nada mais é que a página default do IIS (iisstart).

Após criar o website no seu webserver e requisitar o seu certificado, ele deverá ser validado em um CA Externa ou na sua própria CA Interna (para o caso de aplicações internas que não serão compartilhadas com parceiros ou usuários externos) – Estou assumindo que o leitor deste post já sabe como fazê-lo.

A partir do certificado gerado e validado, exporte-o para um arquivo pfx e o copie para um compartilhamento no seu file server que será o repositório de certificados do IIS para sua estrutura.

OBS: o nome do arquivo PFX deverá ser o mesmo do common name do seu certificado, no exemplo que veremos aqui, o common name do meu certificado é www.uilson.net. Neste caso o nome do arquivo deverá ser www.uilson.net.pfx – qualquer coisa diferente disso, o acesso não funciona.

Para criar o PFX a partir do certificado válido, siga os passos abaixo:

Duplo clique no certificado, clicar na aba “Details” e clicar em “Copy to File”

image

O wizard abrirá e você deverá clicar em “Next”. Em seguida você será perguntado sobre exportar ou não a Private Key. No meu caso, vou exportar para este PFX. Após este passo, clique “Next”:

image

Na tela abaixo, selecione a última opção “Export all extended properties” e clique em “Next”:

image

Na tela abaixo defina uma senha para o arquivo PFX. No meu caso a senha nada mais é que 123456 (é apenas um lab ok?). Em seguida clique “Next”:

image

Na tela abaixo clique em “Browse”:

image 

Agora defina a pasta (compartilhamento) onde o arquivo deverá ser gravado. Obviamente, respeitando o que disse acima sobre o nome do arquivo. Feito isso, clique em “Save”:

image

Na tela abaixo, clique “Next”:

image

Na tela abaixo clique em “Finish”:

image

Você irá receber um aviso dizendo que o export ocorreu com sucesso. Clique em “OK” para fechar o aviso e OK para fechar as propriedades do certificado.

Agora que o certificado está validado, o PFX criado e copiado na pasta correta, vamos configurar o IIS. Entretanto, antes de configurar a aplicação WEB, vc precisa habilitar o serviço do Centralized Certificate Store.

Na imagem abaixo clique no array name (nome do servidor IIS) e no painel a direita de um duplo clique em “Centralized Certificates”:

image

Na tela abaixo vc irá visualizar todos os certificados que estiverem na pasta, ou file share, que foi previamente criado. Para que isso aconteça, clique em “Edit Feature Settings” no lado superior direito:

image

Na tela abaixo, habilitar o checkbox “Enable Centralized Certificates”, configure o caminho UNC do share ou pasta que irá servir de repositório dos seus certificados e defina uma conta que tenha acesso completo a esta pasta para que todos os servidores da sua farm possa ler o conteúdo. Depois você deverá inserir a senha que vc definiu para o arquivo PFX(no nosso exemplo aqui foi 123456). Feito isto, clicar  em “OK”:

image

Com as configurações acima feitas de forma correta, você visualizará o conteúdo do PFX que está no file share ou pasta e agora você já tem o seu primeiro certificado no repositório. Vide imgagem abaixo:

image

Agora que o repositório está configurado, vamos configurar a aplicação WEB para que use o certificado armazenado na CCS.

Clique com o botão direito do mouse no web site e escolha a opção “Edit Bindings…

image

Na tela abaixo clique em “ADD” e a tela “Add Site Biding” irá abrir. No campo “Type” escolha a opção “https” e em “hostname” você poderá inserir o endereço do seu web site. Para que a aplicação WEB use o repositório do Centralized Certificate Store, você deverá selecionar o checkbox “Use Centralized Certificate Store” e clique em OK:

image

Você também tem a opção de habilitar o SNI através do checkbox “Require Server Name Indication”. O SNI é uma extensão TLS usada para identificar o domínio virtual ou o hostname do end point da conexão durante a negociação SSL. Para  habilitar essa opção você precisa ter certeza de que os browsers da sua empresa ou aqueles que vão acessar externamente sejam compatíveis com esta funcionalidade.

As últimas versões do IE têm suporte a este mecanismo, porém, as versões desenvolvidas para o Windows XP não. Portanto, pense nisso antes de habilitar esta opção.

Para ter uma visão detalhada do SNI clique em http://blogs.msdn.com/b/kaushal/archive/2012/09/04/server-name-indication-sni-in-iis-8-windows-server-2012.aspx

Na tela abaixo podemos ver que o site www.uilson.net está pronto para ser acessado via SSL. Clique em “Close”:

image

Ao acessar o site pelo IE, vemos o resultado abaixo:

image

Esta é uma funcionalidade que eu realmente gosto e espero que o conteúdo deste post possa ajudar a você que lida diariamente com uma grande quantidade de servidores WEB IIS.

Abraços

Uilson

Cuidado com URL´s encurtadas a partir do t.co do Twitter

11 de março de 2014 Deixe um comentário

Saudações,

Estou assumindo um novo desafio profissional, este é o motivo da demora em escrever aqui, mas, nesse novo lugar (que espero dar certo) não vão faltar conteúdos interessantes.

Hoje quero deixar uma dica pra quem usa Twitter. Os ataques e tentativas de roubo de identidades acontecem em todos os lugares e hoje, com o uso das URL´s encurtadas, cria-se um novo meio de prejudicar pessoas de boa fé.

Ontem a  noite recebi a notificação de uma mensagem que me foi enviada via twitter. Como conheço a pessoa, logo fui conferir. Ao olhar a mensagem, fiquei meio com o pé atrás, pois, a pessoa é daqui do Brasil e sempre que nos falamos, usamos (obviamente) o português.

A mensagem que ele me passou tinha o seguinte conteúdo:

“rofl this was posted by you? http://t.co/ByZJPUSEiq “ – Não vou aqui expor minha conta no twitter ou a da pessoa que, supostamente, enviou a mensagem

Note que neste caso, o autor desta tentativa de roubar minhas credenciais usou do próprio encurtador de URL´s do twitter para tal.

Como desconfiei logo de cara da forma como a mensagem chegou (em inglês), procurei sites que analisam e mostram o conteúdo de uma URL encurtada, porém, em nenhum deles, a URL original pôde ser exposta.

Em um celular antigo e sem uso cliquei na URL que me levou para uma tela de logon do twitter conforme abaixo:

wp_ss_20140310_0001

Note que neste momento é possível ver a URL de destino:

http://103.242.2.28/login/user-token-8234k89HrK1251jk922JX14895Hs55g3XSFEjfc1/twitter.com/verify-login

Neste ponto o usuário tem a falsa impressão que precisa de autenticar no twitter para poder acessar o link e aí, suas credenciais são roubadas e o resultado disso não é nada bom.

Veja a origem deste IP:

103.242.2.28 IP address location & more:

IP address:103.242.2.28

IP country code:HK

IP address country: ip address flag Hong Kong

IP address state: n/a

IP address city: n/a

ISP of this IP: Pang International Limited-AS number

Organization: Pang International Limited-AS number

Veja abaixo o IP real do t.co (encurtador de URL´s do Twitter):

image

E também as informações reais do domínio t.co:

Host of the IP: t.co

Host IP: 199.16.156.1

IP country code: US

IP address country: ip address flag United States

IP address state: California

IP address city: San Francisco

IP postcode: 94107

ISP of this IP: Twitter

Organization: Twitter

Informações mais completas né?

O autor desta tentativa de ataque deve ter se aproveitado de alguma vulnerabilidade no encurtador do twitter para isso e, não somente a mim, mas a muitos deve ter enviado esse link e, nesse caso, não temos antivirus ou técnicas avançadas que evitem isso…a pessoa tem que ver se aquilo realmente veio do seu contato e, na desconfiança, entrar em contato com ele(a).

Segundo o site www.techguru.com.br – “Trata-se da segunda grande falha do tipo XSS (cross-site scripting) somente neste mês, já que na primeira quinzena outra falha permitia que senhas dos usuários fossem roubadas através de um link malicioso.” – trecho extraído da matéria em http://www.techguru.com.br/mais-um-virus-aflige-o-twitter/ – não chega a ser um vírus, mas, sua disseminação vai depender da interação do usuário – palavras do autor do post.

Mantenha-se seguro, pense bem antes de abrir aquilo que chega pra vc! Estas recomendações são para qualquer browser ou sistema operacional…vai além da tecnologia usada.

Abraços

Uilson

 

PS: As informações dos IP´s listados acima foram coletadas no site – http://www.ip-adress.com

CategoriasNão categorizado

NTLM e Kerberos–Você sabe a diferença entre ambos?

18 de fevereiro de 2014 Deixe um comentário

Saudações,

A alguns anos atrás essa pergunta me foi feita e me enrolei pra responder, ou seja, só consegui responder de forma resumida, não alcançando o objetivo da pergunta.

Depois de algum tempo, consegui entender a diferença e como definir quando a conexão HTTP usa uma ou outra.

Nesse video que fiz sobre o tema, você pode entender perfeitamente como cada uma delas procede:

 

Métodos de conexão HTTP

 

Espero que possa ser útil pra vc que ainda precisa entender esses métodos!

Abraços

Uilson

Erro 105–NLB Cluster–Timer starvation has been detected

17 de fevereiro de 2014 Deixe um comentário

Saudações,

Queria, antes de qualquer coisa, agradecer a todos que participaram da minha palestra sobre Segurança para Redes Microsoft no evento de WebCasts realizado pelo grupo MTAC (Microsoft Technical Audience Contributor).

Espero que tenham gostado e que o conteúdo possa ajudar no dia a dia!

Essa semana me deparei – na prática – com um erro que ainda não tinha visto e  somente tinha lido a respeito.

Durante um consumo excessivo em seu servidor WEB ou para quem ainda usa Forefront TMG em balanceamento de carga, o erro abaixo pode ocorrer:

image

Como lidar com isso? Porque acontece?

Em resumo este problema pode ocorrer em algumas situações:

1. Ataques de origens internas 

Um ataque vindo de uma ou várias estações infectadas, enviando muitas requisições ao servidor gerando um DoS e vindo consequentemente a parar o serviço, causando transtorno para os usuários que precisam do acesso a este servidor, seja ele proxy ou WEB Server.

Neste caso analise bem as origens, ou seja, de onde as requisições vêm e tente determinar se realmente se trata de um ataque.

Caso você determine que uma ou várias estações estão enviando um número absurdo de requisições a um determinado ambiente em NLB, tome as precauções de prache, tais como, scan, análise do acesso em si, ou seja, mitigar o problema a partir da origem.

Em alguns casos, seu proxy ou web server pode estar sofrendo um ataque por conta de um problema em seu roteador ou swtiche que, recebe a requisição e após um travamento ou algo do gênero (não posso adentrar muito nesse mérito, pois, não tenho skill em routers), pode reter requisições de determinadas origens fazendo as mesmas entrar em looping, repetindo constantemente o acesso ao servidor, fazendo com que o erro 105 ocorra.

Neste caso, o suporte da equipe de networking é fundamental para determinar e resolver o problema, uma vez que, ao se descobrir os IP´s de origem, você, ao analisar a estação verá que a mesma não tem nenhum tipo de malware, ou, no caso de um ataque a um servidor de proxy, descobrirá que o acesso requerido não deveria causar tamanho dissabor!

O único problema aí é que, ultimamente, quando se trata de análises de requisições para WEB via um proxy (Forefront TMG ou outro qualquer) em que se pede análise em devices de rede, os responsáveis pelos mesmos se sentem ofendidos como se, analisar o seu device de rede fosse uma ofensa pessoal…portanto, você que lê este post e atua com routers, não leve isso para o lado pessoal, em uma análise mais complexa, muitos pontos da infra devem ser verificados e os devices de rede não ficam de fora…ou não deveriam ficar…rs.

2. Insuficiência de recursos

Como pode ser visto na imagem acima, a explicação para o Erro 105 no NLB também pode ser referente a insuficiência de recursos, ou seja, a quantidade de equipamentos em balanceamento podem não ser suficientes para suportar toda carga de acessos.

Neste caso, adicione um ou mais nodes a sua estrutura de servidores. Para situações em que o erro 105 ocorra em estruturas de WEB Servers, siga o passo a passo do KB abaixo:

http://msdn.microsoft.com/en-us/library/cc726481(v=ws.10).aspx

Neste KB, além da definição do erro 105, você encontra o passo a passo de como incluir mais nodes em sua estrutura de WEB Servers em NLB.

Para o caso de servidores de proxy, siga as instruções do fabricante de seu produto. No caso de Forefront TMG, instale um novo servidor com as mesmas características daqueles que já estão em produção, faça o deploy do Forefront TMG e o insira no array produtivo. Mais informações sobre isso, faça uma pesquisa neste blog na caixa localizada no canto superior direito para encontrar posts relacionados.

Para evitar esse tipo de problema, faça sempre um planejamento sério e eficaz, prevendo crescimento e dando ao cliente um tempo de vida útil para o ambiente (seja ele qual for).

Para mais detalhes sobre planejamento de estruturas de TI, façam também uma pesquisa neste blog.

Espero que o conteúdo possa ajudar!

Gostaria de agradecer meu amigo Gilberto Okoti pela explicação a respeito da parte dos devices de rede e que ajudaram na solução do problema e montagem deste post!

Um abraço!

Uilson

 

Habilitando SMB Encryption via Power Shell

3 de fevereiro de 2014 Deixe um comentário

Saudações,

Faltam dois dias para meu webcast sobre Segurança em Redes Microsoft. Para participar, simplesmente clique na imagem abaixo para participar (na data e horário):

uilson

Bom, propaganda feita! Vamos ao tema principal desse post!

Como já tive oportunidade de falar em alguns webcasts, o Windows Server 2012 R2 tem uma feature de segurança muito importante que vem agregar a seu ambiente.

Trata-se do SMB Encryption. Um sistema de encriptação de fim a fim que visa proteger a comunicação através dos compartilhamentos criados em uma pasta de arquivos.

Para habilitar a feature, basta selecionar um check-box nas propriedades do compartilhamento da pasta. Quer ver na prática? Então assista a meu webcast do próximo dia 05 as 20 hs que irei mostrar.

Mas aqui este post, vou mostrar como fazê-lo via Power Shell.

Use o seguinte comando para habilitaro SMB Encryption:

Set-SmbShare –Name <sharename> -EncryptData $true

Se você possui uma infra estrutura onde todas requisições entendem a versão 3.0 do SMB e desja que toda comunicação de seus File Servers já encriptada, use o seguinte comando para habilitar o SMB Encryption em todas as pastas compartilhadas:

Set-SmbServerConfiguration –EncryptData $true

O comando acima, como já dito, vai habilitar o SMB Encryption em todos os seus compartilhamentos, porém, você não poderá desabilitar a feature em uma única pasta, pois, a opção ficará desabilitada para alterações, portanto, pense bem antes de tomar essa decisão.

E por último, porém, não menos importante, você pode ter em sua rede alguns clientes que não suportem o SMB 3.0, independente de ter todas ou algumas pastas protegidas pela feature. Para evitar problemas com estes clientes, vc pode permitir que acessos sem encriptação sejam aceitos pelo SMB Encryption. Para tanto, use o comando Power Shell abaixo:

Set-SmbServerConfiguration –RejectUnencryptedAccess $false

Espero que as dicas seja úteis e que você participe do WebCast na próxima quarta (05/02).

Abraços

Uilson

WebCasts do grupo MTAC – Inscrições Abertas

23 de janeiro de 2014 Deixe um comentário

Saudações,

A demora em postar conteúdo aqui se deve a um período de transição que estou passando e que em breve vou divulgar aqui, mas, a intenção é falar sobre o evento “Technical Audiences” promovido pelo grupo MTAC (Microsoft Technical Audience Contributor).

Palestras com 1:30 hs de duração sobre temas variados em infra e dev para Microsoft.

A minha palestra será a primeira – 05/fevereiro as 20 hs – onde tratarei mais uma vez do tema “Segurança em Redes Microsoft”.

Falei sobre este tema no MVP ShowCast e no Quintas de TI e, como se trata de um assunto muito importante, resolvi insistir nele para deixar bem marcado nos ouvintes a importância do bom planejamento de segurança desde a concepção do projeto de instalação do servidor em Rack, até as melhores práticas em servidores Windows e ferramentas como WAP (Web Application Proxy), ARR (Application Request Routing), WSUS e 802.1x.

As inscrições podem ser feitas no site do grupo MTAC (http://www.aka.ms/mtac) e abaixo vai o banner do evento onde vc poderá ver todo o conteúdo que será apresentado no mês de fevereiro:

1620309_575629729171859_1148208001_n

Espero que gostem do conteúdo e que seja de grande utilidade em seu dia a dia.

Abraços

Uilson

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 883 outros seguidores

%d blogueiros gostam disto: