Web Dev & Infra: qual o seu lado?

Como resolver o erro “Request is not available in this context”

Paulo Teixeira - MSFT — Wed, 20 Feb 2013 17:42:00 GMT

Você está trabalhando para migrar uma aplicação .NET do IIS6 para o IIS 7.x/8 e após fazer toda a configuração imediatamente no primeiro acesso já recebe a seguinte mensagem de erro:

Request is not available in this context

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Request is not available in this context

Logo abaixo você poderá encontrar detalhes adicionais (linha onde ocorreu o erro) além de uma pilha similar ao seguinte:

[HttpException (0x80004005): Request is not available in this context]
System.Web.HttpContext.get_Request() +3467061    ASP.global_asax.Application_Start(Object source,
EventArgs e) in c:\inetpub\wwwroot\global.asax:5

[HttpException (0x80004005): Request is not available in this context]
System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(…

Como podemos observar, o erro foi gerado no módulo/método ASP.global_asax.Application_Start da aplicação. Este é um problema conhecido quando se faz a migração de aplicações ASP.NET do IIS6 para versões superiores, e está descrito no seguinte blog: http://mvolo.com/iis7-integrated-mode-request-is-not-available-in-this-context-exception-in-applicationstart

Para resolver o problema você precisará solicitar ao desenvolvedor que abra o arquivo GLOBAL.ASAX.CS (ou .VB) da aplicação e localize, dentro do método ApplicationStart() qualquer uso do objeto HttpContext.Current.Request. Em geral você encontrará algo como:

str = HttpContext.Current.Request.QueryString["key"];

Será necessário remover este código substituindo-o por algum outro mecanismo. A explicação para este erro é bem simples: no IIS7 o novo pipeline integrado irá executar o método Application_Start() antes que qualquer request chegue ao servidor, e portanto, o objeto Request não está disponível.

Um abraço e até a próxima,

Tracing de aplicações ASP.NET no IIS 7.x/8

Paulo Teixeira - MSFT — Mon, 18 Feb 2013 11:25:00 GMT

Olá pessoal!

Poucos desenvolvedores fazem uso de um dos recursos mais interessantes disponíveis para aplicações ASP.NET, a capacidade de criar traces diretamente a partir do seu código e usá-los para resolver problemas durante a etapa de desenvolvimento.

O uso de "técnicas para criação de traces" é algo muito comum: lembra-se de ter escrito um bom e velho "Response.Write" em aplicações ASP Clássico para validar se os dados em uma determinada rotina está conforme o esperado? Pois é... era assim no ASP Clássico, em C, C++, etc

Nas aplicações ASP.NET este processo é realmente muito simples: basta habilitar o registro de entradas de trace no arquivo web.config, adicionando a seguinte tag:

Maiores detalhes sobre a diretiva <trace> do arquivo web.config pode ser obtida em: http://msdn.microsoft.com/en-us/library/6915t83k(v=vs.80).aspx

Com a diretiva trace configurada no seu arquivo web.config agora basta adicionar as diretivas de trace em sua aplicação. O desenvolvedor deverá adicionar algumas linhas de código na sua aplicação, para imprimir os valores que precisam ser validados. Para isso, em cada modulo que se deseja utilizer o trace, deve-se adicionar o namespace System.Web. Um exemplo simples do uso de trace em uma página ASP.NET (em C# e .NET Framework 4.5) é mostrado a seguir:

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace TraceSample
{
public partial class LongRunningPage : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
      //
      // This is just a page where any GET requests will take...
      // well, very long

Trace.Warn("Warning! Entering in the PAGE_LOAD event");

      DateTime start = DateTime.Now;
      int delay = new Random().Next(5000, 15000);
      Thread.Sleep(delay);

DateTime end = DateTime.Now;
myLabel.Text = String.Format("Total page exec took:{0} ms", (end - start).TotalMilliseconds);

Trace.Write("PAGE_LOAD event finished");

}
}
}

No código acima você encontra duas diretivas: Trace.Warn e Trace.Write ... existem poucas diferenças entre elas, a mais visível é que a primeira irá produzir uma entrada em vermelho na saída do trace.

Uma vez que o código da aplicação tenha sido ajustado para criar a saída necessária, você poderá acessar a página e testar a sua aplicação. Após ter executado a página, você poderá visualizar o resultado do trace através do handler TRACE.AXD. Por exemplo, se a página chama-se LongRunning.aspx., você deve primeiro chamar:

http://meusite/LongRunning.aspx

e depois:

http://meusite/trace.axd

Com isso, uma página de trace similar ao seguinte sera exibida:

Ao se clicar em uma das entradas você poderá observer detalhes do trace daquela página, algo similar ao seguinte:

Acima podemos ver o resultado das diretivas de trace que foram adicionadas no código da aplicação. Voilá!

Agora, o mais um ponto: É possível visualizar o resultado das diretivas Trace.Warn nos logs FREB (ou Failed Request Tracing) do IIS. Basta configurar o seu servidor para gerar este tipo de log (conforme as regras que você estabelecer) e ao visualizá-lo você encontrará as saídas geradas pelo seu aplicativo. Esta é a outra diferença entre as duas diretivas: Trace.Write não irá aparecer nos logs do IIS, e portanto, se precisar usar este recurso de uma forma regular, use somente o Trace.Warn.

E finalmente, aquela dica de sempre: não deixe as diretivas de trace habilitadas em servidores de produção! Sempre podem existir questões relacionadas à segurança de sua aplicação e não custa descuidar!

É isso ai! Não perca tempo e aproveite para usar este recurso durante o processo de desenvolvimento da sua aplicação.

Abraços,

Qual a diferença entre Web Site Project e Web Application Project no Visual Studio?

Paulo Teixeira - MSFT — Tue, 12 Feb 2013 23:50:00 GMT

Faz um tempo um cliente me perguntou a diferença entre Web Site e Web Application.De início eu nem tinha entendido direito a pergunta, mas depois ficou claro a dúvida: a questão estava relacionada aos tipos de projeto disponíveis no Visual Studio.

No Visual Studio, você pode escolher entre dois tipos de projetos Web: Web Site Project (WSP) ou o Web Application Project (WAP).

A grande diferença entre estes dois tipos de projeto é a forma que ocorre o deployment da aplicação. Em um Web Site Project o Visual Studio irá fazer a publicação de todos os arquivos do projeto (incluíndo o código-fonte da sua aplicação). Já em um Web Application Project somente será publicado o código HTML (markup) e o código compilado da sua aplicação.

Em outras palavras, em um Web Application Project o Visual Studio irá se encarregar de compilar a sua aplicação, gerando vários binarios dentro da pasta /BIN. Ao se fazer a publicação somente estes arquivos serão colocados no servidor Web.

Existem prós e contras para cada um dos tipos de projeto, mas eu pessoalmente sou muito mais a favor do uso de Web Application Projects, por um fator muito simples: você evita que o código-fonte fique visível no servidor Web (ponto para a questão de segurança), e também evita que o servidor Web fique responsável pela compilação da aplicação durante o primeiro acesso (uma outra hora faço um post com mais detalhes sobre isso).

Uma comparação mais detalhada entre estes dois tipos de projeto pode ser encontrada em http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5 (em inglês)

[]s
PT

Como fazer Interop de componentes COM+ 32bits em aplicações .NET 64bits

Paulo Teixeira - MSFT — Mon, 11 Feb 2013 10:00:00 GMT

Olá pessoal! Imagine o seguinte cenário:

Você possui uma aplicação antiga construída em ASP.NET mas que por algum motivo específico ainda usa componentes COM através de Interop.

Este, apesar de não desejado, é um cenário muito comum, em particular em ambientes corporativos: muitas vezes os componentes COM foram construídos em VB6 ou VC++ e encapsulam regras de negócio que não mudaram. Como as áreas de TI nem sempre possuem orçamento para fazer a conversão deste código para uma linguagem .NET como o Visual Basic.NET ou C#, esses componentes costumam ser usados por um logo período de tempo, até que um novo projeto substitua inteiramente a aplicação.

Agora, imagine que a área de TI da empresa resolve evoluir a plataforma Web para as versões mais recentes do Windows Server, só disponíveis em 64-bits. Para este cenário sempre existe a possibilidade de rodar os Application Pools do IIS 7.x (e superior) em modo 32-bits, mas seria desejável que asp aplicações ASP.NET pudessem explorar o máximo da nova plataforma, com o poder total da arquitetura 64-bits. Mas ai, surge o problema dos velhos componentes VB6 32-bits. Por padrão, não é possível carregar uma DLL (Componente COM) 32-bits em um processo (Application Pool) 64-bits. O que fazer???

Uma forma simples de continuar utilizando o código legado desses componentes COM de 32-bits sem custo extra é passar a usá-los no COM+ (Component Services). Basta seguir os seguintes passos:

Primeiro, se você tiver registrado a DLL do seu componente no seu Windows x64, você terá que desfazer este processo. Execute o comando “regsvr32 /u <path_e_nome_da_dll>”
Vá no Control Panel / Administrative Tools/ Component Services. Depois, no treeview abra My Computer, e então COM+ Applications. Clique com o botão direito e selecione “New –> Application”
Na tela “Welcome to the COM Application Install Wizard” clique em “Next >”.
Selecione o botão “Create an Empty Application”.
Dê um nome para a sua aplicação (qualquer nome serve, mas é bom colocar algo que lembre o nome do componente que será executado). Depois entre “Library / Server”, selecione o tipo “Server”.
Clique em “Next >” e depois “This User”.
Selecione o usuário com o qual o componente será executado. Pode ser um usuário de domínio previamente criado para executar o componente ou um dos usuários de sistema existentes (NOTA: escolha o usuário tentando manter o mais seguro possível; evite LOCAL SYSTEM pois o mesmo tem direitos de administrador no Sistema Operacional, a menos que isso seja um pré-requisito da aplicação).
Depois pressione “Next >” nas telas seguintes (não altere nada), até concluir a criação da aplicação.
O próximo passo é adicionar o seu componente a esta aplicação recém-criada. Você encontrará a aplicação em Component Services -> Computers -> My Computer -> COM+ Application . Clique no ícone “+” e você verá um item “Components”. Selecione este item.
Usando o Windows Explorer, arraste a DLL para a janela à direita na tela em “Components”. Com isso o componente será registrado automaticamente no Component Services. Aparecerá um ícone de forma circular e de cor amarelada que representa o Componente recém-instalado.
Em seguida vá em Component Services -> Computers -> My Computer -> COM+ Application e selecione sua aplicação. Clique com o botão direito e abra as propriedades selecionando “Properties” no menu de contexto.
Clique na guia “Security” e em “Authorization” desmarque a opção “Enforce access checks for this application”.
Em “Security Level” marque a opção “Perform access checks only at the process level.”
Também garanta que “Apply restriction policy” está desmarcado.
Configure o “Impersonate Level” para “Anonymous”
O último passo será garantir que o usuário que roda o Application Pool poderá utilizar o seu componente. Para isso, em COM+ Application –> <Nome_da_sua_aplicacao> -> Roles -> CreateOwner –> Users você deverá adicionar o usuário do IIS (em geral IUSR) ou o grupo IIS_USRS (para o IIS 7.X/8).
Também garanta que a pasta onde está instalado o componente esteja com permissões NTFS que permitam ao usuário do Application Pool possa ler o arquivo do componente. Em geral é suficiente adicionar a permissão de Execução nesta pasta para o grupo IIS_USRS.

NOTAS:

a) As configurações de segurança do componente (em amarelo acima) podem variar, se o mesmo necessitar personificar o usuário (i.e. rodar sobre o contexto de um outro usuário, por exemplo, para acessar um banco de dados ou outro recurso externo).
b) Se estiver usando o Pipeline Classico do IIS 7.x talvez seja necessário adicionar também o usuário IUSR e IWAM quando estiver atribuindo as permissões no Component Services e nas permissões NTFS da pasta.

Agora basta testar a sua aplicação. Configure o Application Pool para rodar em modo 64bits e faça o teste: a aplicação, mesmo usando componentes antigos escritos em VB6 deverá executar sem problemas.

Até a próxima!

Varrendo a poeira!

Paulo Teixeira - MSFT — Sat, 09 Feb 2013 18:00:01 GMT

Olá pessoal!

Esse é só um post daqueles que a gente escreve para dizer que está fazendo uma faxina na casa. Aproveitando a inspiração de ontem, acabei fazendo uns updates nos posts antigos sobre ARR (pouca coisa, somente umas referências atualizadas e algumas informações adicionais para deixar o conteúdo mais claro).

Também devo iniciar uma série de posts sobre assuntos diversos, boa parte deles com foco em problemas que ocorrem durante a migração de aplicações de IIS5/6 (32bits) para IIS 7.x/8.

A gente se vê em breve!

[]s
PT

Monitorando aplicações COM+

Paulo Teixeira - MSFT — Fri, 08 Feb 2013 18:27:38 GMT

Já faz um tempo que não publico nada, mas esta semana um outro colega esteve trabalhando num caso muito interessante. Ele estava fazendo o diagnóstico de uma aplicação Web que havia sido migrada para o Windows 2008 R2.

Esta aplicação usa componentes COM+ e em algum momento, o componente simplesmente travava (cenário típico de Hang).
Os componentes são antigos, e não se tem o código-fonte dos mesmos. Após muita investigação, descobriu-se que o componente iniciava um outro processo no Windows para realizar uma tarefa específica. Quando o COM+, por algum motivo realizava o RECYCLE do processo DLLHOST.exe onde o componente estava sendo executado, este outro processo permanecia em execução.

Na próxima chamada ao componente, o mesmo tentava executar o outro processo, mas já havia uma instância em execução e por isso o componente travava. A melhor solução seria reescrever todo o componente de forma que o mesmo utilize técnicas mais modernas para executar as tarefas a que se propõe, mas infelizmente isso é impossível.

Neste caso, uma solução de contorno foi necessária. Para eliminar o travamento, bastou desabilitar o RECYCLING da aplicação COM+ no snap-in dos serviços de componente (Component Services).

Todavia, um novo problema surge com essa abordagem, que é o fato que agora o processo DLLHOST.exe do COM+ poderá travar em função de algum outro mau comportamento ou até mesmo devido ao processo natural de fragmentação de memória (outro dia faço um post sobre isso).

Para minimizar esse problema seria ideal ter uma ferramenta que monitore o comportamento da aplicação COM+ (“AppBugada”, no exemplo da imagem acima) e em caso de consumo de um certo limite de memória virtual, que ela seja automaticamente encerrada.

Para isso, um script foi usado a fim de monitorar a aplicação COM+. Veja abaixo um exemplo similar que também pode ser usado para fazer este tipo de objetivo:

NOTA: Este script é um código-exemplo, use por sua conta e risco. Não oferecemos suporte a este script e não nos responsabilizamos por eventuais consequências adversas devido ao seu uso num ambiente de produção.

strComputer = "."
strCOMAppName = "AppBugada"
constMemLimit = 999999999 'Bytes
constRunning = false
constCOMAppFound = false

Set objCOMCatalog = CreateObject("COMAdmin.COMAdminCatalog")
Set objCOMApps = objCOMCatalog.GetCollection("Applications")
objCOMApps.Populate

For each objCOMApp in objCOMApps
    If objCOMApp.Name = strCOMAppName then
        Set objCOMAppInstances = objCOMApps.GetCollection("ApplicationInstances",objCOMApp.Key)
        objCOMAppInstances.Populate
        For each objCOMInstance in objCOMAppInstances
            PID = objCOMInstance.Value("ProcessID")
            constRunning = not ( objCOMInstance.Value("IsPaused") or objCOMInstance.Value("HasRecycled"))
            If constRunning then
                Set objWMIService = GetObject("winmgmts:" _
                    & "{impersonationLevel=impersonate}!\\" _
                    & strComputer & "\root\cimv2")
                Set objProcesses = objWMIService.ExecQuery _
                   ("Select * from Win32_Process where ProcessId='" & PID & "'")
                For Each objProcess in objProcesses
                    Wscript.Echo "Process: " & objProcess.Name
                    sngProcessTime = (CSng(objProcess.KernelModeTime) + _
                        CSng(objProcess.UserModeTime)) / 10000000
                    Wscript.Echo "Processor Time: " & sngProcessTime
                    Wscript.Echo "Process ID: " & objProcess.ProcessID
                    Wscript.Echo "Peak Virtual Size: " _
                    & objProcess.PeakVirtualSize
                    Wscript.Echo "Virtual Size: " _
                    & objProcess.VirtualSize
                    If objProcess.VirtualSize > constMemLimit then
                        objProcess.Terminate()
                    End if
                Next
                Set objWMIService = nothing
                Set objProcesses = nothing
                Exit For
            Else
                Wscript.Echo "COM+ Application not running."
            End if
        Next
        Set objCOMAppInstances = nothing
        constCOMAppFound = true
        Exit For
    End if
Next

If constCOMAppFound = false then
        Wscript.Echo "COM+ Application not found."
End if

Set objCOMApps = nothing
Set objCOMCatalog = nothing

O Script usa a interface COMAdmin para monitorar as aplicações COM+ e classes WMI para coletar informações do processo DLLHOST.exe correspondente. Caso o processo atinja um certo limite de uso de memória virtual, o mesmo será terminado.

Valeu pessoal e até a próxima.

Localizando assemblies compilados em modo debug

Paulo Teixeira - MSFT — Fri, 05 Aug 2011 09:26:00 GMT

No meu último post eu comentei os problemas que pode ocorrer ao se publicar uma aplicação Web em modo debug para a produção.

Com isso, ficou uma dúvida: como saber se o meu website possui aplicações publicadas em modo debug. Uma forma muito simples de verificar isso é localizar o arquivo web.config e procurar pela diretiva <compilation debug=”true”>.

Mas eu vou mostrar uma outra técnica diferente aqui, que se baseia na inspeção de cada uma das DLLs contidas nas pastas de conteúdo do seu site.

Isso porque, eventualmente uma aplicação foi compilada em modo debug, e depois cpiada para produção, e então teve o seu arquivo web.config alterado (ajustado). O que pode ocorrer é que há DLLs em modo debug, mesmo com a diretiva já marcada como FALSE.

Vamos usar um script powershell 2.0 que varre as pastas a partir de um certa pasta, e localiza todos os arquivos .exe e .dll. Depois usamos o namespace System.Reflection.Assembly para verificar se foi compilado em modo debug ou release (atributo isJITTrackingEnabled).

Se a DLL não for compilada com .NET, será gerada um exceção e nada será escrito, caso contrário, uma mensagem com o nome e o atributo debug é exibido. Veja o código-exemplo a seguir:

#
# List Assemblies - requires a path
#
PARAM
(
    [string] $path = ""
)

    # List assemblies
    "Assemblies using debug mode"
    $files = dir -recurse -path $path -include "*.dll", "*.exe"
    foreach($file in $files)
    {
        try {
            $assembly = [System.Reflection.Assembly]::LoadFile($file);
            $attrib = $assembly.GetCustomAttributes($false) | where-object { $_ -is

[System.Diagnostics.DebuggableAttribute] }
            if ( $attrib.IsJITTrackingEnabled )   {
                  $debug = 'Debug';
            } else {
                  $debug = 'Release';
            }
            $version = $assembly.ImageRuntimeVersion;
            $file.FullName.ToLower().Replace($path.ToLower(),'') + " | " + $debug + " | " + $version ;
        } catch [System.Management.Automation.MethodInvocationException]
        {

        }
    }

DISCLAIMER: o código acima é fornecido “as is”, e sem garantias. Use por sua conta e risco.

Com isso, fica bem mais fácil identificar se há aplicações em modo DEBUG. Você pode usar a mesma abordagem para criar uma aplicação .NET (ou um Windows Service)

Até mais!

Compilation Debug=”true”, uma odisséia

Paulo Teixeira - MSFT — Sat, 30 Jul 2011 21:41:21 GMT

Este é mais uma daqueles posts que retrata a sempre tensa relação entre os administradores de Servidores Web e os desenvolvedores de aplicações ASP.NET.

Resolvi escrever isso porque ontem estava conversando com um cliente e ele estava com dúvidas sobre o uso (ou não) dessa diretiva nos arquivos web.config das aplicações ASP.NET.

A pergunta que sempre se faz é a seguinte: Em que momento devo usar a diretiva <compilation debug=”true”/> em minhas aplicações ASP.NET. Semprem surgem duvidas em relação a resposta para esta questão, então vou tentar ser bem claro: NUNCA!!

O grande problema é que, por padrão, quando o desenvolvedor está criando a sua aplicação, é necessário ter esta diretiva habilitada para poder fazer o debugging da aplicação. Assim, o Visual Studio por padrão deixa o <compilation debug=”true” /> quando está se gerando um build em modo Debug. Por outro lado, se o código da aplicação for compilado em modo RELEASE, então teremos o <compilation debug=”false” />.

Cabe deixar bem claro que é responsabilidade do desenvolvedor gerar um build em modo RELEASE antes de enviar para a publicação no servidor Web. É também é responsabilidade do administrador de servidores Web garantir que não serão publicados builds em modo debug no ambiente de produção Web.

Há uma miríade de artigos explicando os problemas causados pelo deployment de aplicações em modo debug, então vou apontar um oficial que resume-os: http://support.microsoft.com/kb/2580348.

Para desabilitar o modo debug nas aplicações Web, basta seguir as recomendações do artigo: http://support.microsoft.com/kb/815157.

Algo que poucos sabem é que os administradores de servidores Web podem evitar que aplicações sejam publicadas em modo debug nos seus servidores, para o .NET Framework 2.0 e versões posteriores. Para isso, basta alterar o arquivo machine.config, adicionando a diretiva <deployment retail=”true” />, como exemplificado:

Com isso, o debugging será desabilitado para todas as aplicações. Mas mesmo assim, se uma aplicação ainda estiver configurada para usar <compilation debug=”true” />, então o executionTimeout (ou seja, o tempo máximo que uma página pode executar) continuará sendo 30.000.000 segundos (ou seja, muiiiito tempo).

Resumindo, <deployment retail=”true” /> ajuda, mas não resolve o problema totalmente.

Então, DEVs e WebAdmins, fiquem atentos e não se esqueçam de sempre confirmar que as aplicações estão sendo publicadas em modo release no ambiente de produção.

Até mais!

Paulo.

Como desabilitar o SSLv2 e o PCT v1 no IIS6 e IIS7.x

Paulo Teixeira - MSFT — Sat, 28 May 2011 21:45:19 GMT

Já faz algum tempo que se sabe que o protocolo SSL v2 é suscetível a ataques do tipo “man-in-the-middle”. Mas a menos tempo as empresas especializadas em testes de intrusão começaram a fazer testes e colocar este protocolo na “lista negra” das vulnerabilidades pelo qual o seu web site pode ser atacado.

Recentemente montei um pequeno laboratório para desabilitar estes protocolos no Windows 2003, Windows 2008 e Windows 2008 R2, a pedido de um cliente. A melhor forma de fazer isso nestas versões do Windows é através do Schannel. O Schannel é um Security Support Provider utilizado no Windows por aplicações de Internet (como o IIS) que necessitam comunicações seguras via HTTP. O Schannel oferece autenticação e comunicações seguras e privadas através do uso de criptografia.

O procedimento consiste em remover da lista de protocolos permitidos pelo Schannel aqueles que são considerados fatores de risco, ou que apresentem vulnerabilidades conhecidas. Dessa forma, o SSL v2.0, o PCT 1.0 e as cifras de 40bits e 56bits devem ser desabilitadas. Os passos estão descritos a seguir:

Windows 2003:

No Windows 2003/IIS6, o protocolo SSLv2 está habilitado, juntamente com o PCT 1.0.
Neste caso, o procedimento recomendado para desabilitar estes procotolos e também as cifras de 40 e 56bits é o seguinte:

Crie um arquivo .REG com o seguinte conteúdo:

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Protocols\Multi-Protocol Unified Hello\Server]
"Enabled"=dword:00000000
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Protocols\PCT 1.0\Server]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\DES 56/56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\NULL]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\RC2 128/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\RC2 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\RC2 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\RC4 128/128]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\RC4 64/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\
SCHANNEL\Ciphers\Triple DES 168/168]
"Enabled"=dword:ffffffff

Aplique então este arquivo nos servidores IIS6 e em seguida reinicie os mesmos. Para testar se o protocolo foi desabilitado pode ser utilizado o utilitário WFETCH, que é parte do IIS6 Resource Kit.

Windows 2008 e Windows 2008 R2:

No Windows 2008 e Windows 2008 R2 o protocolo SSL v2.0 está habilitado, mas o protocolo PCT 1.0 já está desabilitado por padrão. Também não há cifras com 40 ou 56 bits habilitadas. De qualquer forma a mesma configuração utilizada no Windows 2003 pode ser aplicada no Windows 2008.

Assim, basta criar um arquivo .REG com o seguinte conteúdo:

Uma outra forma de desabilitar o uso do protocolo SSL v2 no Windows 2008 e Windows 2008 R2 é explicitamente desabilitar as seguints cifras:

SSL_CK_RC4_128_WITH_MD5,
SSL_CK_DES_192_EDE3_CBC_WITH_MD5

Para isso basta seguir os procedimentos sugeridos no artigo:

http://blogs.msdn.com/b/amol/archive/2010/04/27/how-to-disable-ssl-2-0-in-internet-information-services-7.aspx

substituindo os valores padrão a seguir:

TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_RC4_128_MD5,
SSL_CK_RC4_128_WITH_MD5,SSL_CK_DES_192_EDE3_CBC_WITH_MD5,
TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA

Por este novo conjunto de cifras:

Adicionalmente, é recomendado que os websites configurados nos servidores IIS7.x sejam configurados para não permitir o uso de cifras fracas (40bits e 56bits). Para isso, utilizando o Internet Information Services Manager, selecione o website a ser configurado, e no painel de navegação selecione "SSL Settings". Em seguida, configure o site para requerer o uso de cifras de 128bits (marque o checkbox "Require 128-bit SSL"). A figura a seguir ilustra a configuração necessária:

Conclusões

Este procedimento irá desabilitar o protocolo SSL v2.0 e PCT v1.0 removendo-os da lista dos protocolos permitidos no Schannel. Ao se remover os protocolos SSL v2.0 e PCT v1.0 da lista de protocolos permitidos no Schannel, o servidor Web IIS não será mais capaz de estabelecer canais de comunicação utilizando os mesmos, dessa forma evitando que vulnerabilidades conhecidas sejam exploradas. Contudo, clientes antigos ou proprietários que não implementem os protocolos restantes (com o SSL v3.0 ou o TLS 1.0) não conseguirão mais ter acesso ao servidor. Cabe a você avaliar se há aplicações que dependam dos protocolos desabilitados, e o consequente impacto para o seu negócio ao se tomar esta ação.

Referências:

Cipher Suites in Schannel:
http://msdn.microsoft.com/en-us/library/aa374757(VS.85).aspx

Schannel Cipher Suites in Windows Vista:
http://msdn.microsoft.com/en-us/library/ff468651(v=VS.85).aspx

How to disable SSL 2.0 in Internet Information Services 7:
http://blogs.msdn.com/b/amol/archive/2010/04/27/how-to-disable-ssl-2-0-in-internet-information-services-7.aspx

How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services:
http://support.microsoft.com/?id=187498

Prioritizing Schannel Cipher Suites:
http://msdn.microsoft.com/en-us/library/bb870930(VS.85).aspx

Mais um site sobre LogParser

Paulo Teixeira - MSFT — Thu, 05 May 2011 18:43:23 GMT

Confesso que eu tenho um arquivo com as minhas queries de logparser preferidas, mas algumas vezes aparece alguma coisa que não está lá e nessas horas eu recorro a uma pesquisa na Web (usando o Bing!, é claro!)

Num desses dias eu acabei achando o site “LogParserPlus.com”, e encontrei uma série de queries bem interessantes (muitas delas eu já tinha, mas tem outras bem legais lá). Então, ao invés de ficar copiando e colando tudo aqui, passo para vocês o link, vale a pena visitar: logparserplus.com

Abraços,

Paulo.

Otimizando o tempo de carregamento do site – parte 2

Paulo Teixeira - MSFT — Wed, 16 Feb 2011 18:13:59 GMT

Ok, eu havia prometido falar sobre esse assunto, mas já faz um tempo que ando realmente muito ocupado. Hoje, entretanto, num momento de falta de inspiração, resolvi “descansar” a cabeça um pouco, continuando esta série de posts.

Vamos então falar de três dos assuntos abaixo (em vermelho):

paralelização de requests
utilização de compressão
redução de espaços em branco das páginas
evitar a serialização de download do javascript
otimização de tamanho das imagens
cache do lado do servidor
cache do lado do cliente

A idéia aqui é que quanto menos conteúdo você tenha na página, obviamente ela irá carregar mais rapidamente. Assim fica fácil entender por que devemos usar imagens do tamanho apropriado, páginas com pouco código HTML (ou ao menos bem otimizado, usando folhas de estilo CSS), usar compressão, etc..

Todavia, do ponto de vista de quem desenvolve um site Web, muitas vezes é difícil identificar quais páginas são candidatas a optimização. Mais complexo se torna esta tarefa quando falamos de aplicações Web, com páginas sendo geradas dinâmicamente.

Felizmente existem várias ferramentas que podem ser utilizadas para nos auxiliar nesta tarefa, duas delas gratuita e disponível para download no site da Microsoft. A primeira é o Visual RoundTrip Analyzer (VRTA), que pode ser obtido neste link:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=119f3477-dced-41e3-a0e7-d8b5cae893a3

O VRTA requer que o Microsoft Network Monitor esteja instalado para realizar a captura dos dados na rede. A partir daí ele apresenta de forma gráfica e também em forma de relatório diversas informações sobre o tempo de carregamento das páginas. Entre elas, ele apresenta quais páginas estão com uma taxa de compressão baixa, com espaços em branco em excesso, e também imagens com tamanho inadequado (muito pequenas).

Além disso, o VRTA apresenta uma “análise” dos princiapis pontos a serem otimizados no carregamento da página, algo extremamente útil e que pode facilitar a decisão de que tipo de problema você deve atacar primeiro.

A segunda ferramenta é o Internet Explorer 9. Pois é, o IE9 possui um módulo chamado “Developer Tools” que possui diversos recursos muito interessantes. Uma das coisas é que possível fazer é uma captura de rede, de forma idêntica ao VRTA, mas sem requerer o Microsoft NetWork Monitor instalado.

O interessante em relação ao Developer Tools do IE9 é que, além de mostrar informações de forma similar ao VRTA, ele também faz a ligação com o código JScript e DOM que “disparou” o carregamento de um certo componente.

Então ai fica a dica, baixe as duas ferramentas e começe a brincar.
Com tempo voltarei a esse assunto para explorarmos mais possibilidades.

Abraços,

Paulo.

Updates em relação a suportabilidade do .NET Framework

Paulo Teixeira - MSFT — Fri, 12 Nov 2010 01:40:00 GMT

Pessoal, algumas informações em relação ao suporte do .NET Framework:

A Microsoft atualizou sua política de suporte para o .NET Framework, e a partir de agora, começando com o .NET Framework 3.5 Service Pack 1 (SP1) o mesmo será considerado um “Componente”, atrelado ao ciclo de vida do produto “pai”, no caso, o Windows Server.

.NET Framework versões 3.0 e 3.5: ambas as versões continuam suportadas até 12 de Abril de 2011. A partir desta data o suporte a essas versões será encerrado.

É altamente recomendável que caso possua aplicações escritas com essas versões do Framework, você se prepare para atualizar para o .NET Framework 3.5 SP1 antes de 12 de Abril de 2011.

E sobre as versões 1.1 e 2.0 do Framework?

O suporte ao .NET Framework 1.1 se encerra em 8 de Outubro de 2013; para obter suporte você deve estar usando o último Service Pack disponível.
O suporte ao .NET Framework 2.0 termina em 12 de Abril de 2016; para obter suporte você deve estar usando o último Service Pack disponível.

Nota: estas datas podem sofrer alterações. Para confirmar se as mesmas continuam válidas, acesse: http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=.net+framework&Filter=FilterNO

Para maiores informações, visite o site http://support.microsoft.com/gp/lifeandotnet ou entre em contato via email através do endereço mslpm@microsoft.com (preferivelmente em inglês).

Recursos do Microsoft Lifecycle

· MSL Web site – site oficial sobre o ciclo de vida de produtos Microsoft.

· MSL Newsletter Sign-up - para receber atualizações via email do ciclo de vida de produtos Microsoft

· MSL Blog – Blog sobre o ciclo de vida de produtos Microsoft

Vulnerabilidade do ASP.NET – hotfix disponível!!!!

Paulo Teixeira - MSFT — Tue, 28 Sep 2010 18:52:33 GMT

Há diversos blogs na Internet falando da vulnerabilidade do ASP.NET recentemente descoberta que permite o acesso no servidor Web, tantos que optei por não escrever nada no meu.

Porém a alguns minutos atrás foi lançado o hotfix para todas as versões afetadas pelo bug. Mais informações podem ser obtidas em:

http://www.microsoft.com/technet/security/bulletin/MS10-070.mspx

Alguns pontos importantes:

Vou instalar no Windows 2008 R2, mas não encontro o pacote para o framework 2.0 para download
Não tem problema, instale a versão do framework 3.5.x e ele irá “corrigir” também a versão 2.0 (como devem saber, o 3.5.x é um superconjunto do 2.0).
Preciso instalar o hotfix no Server Core?
Sim, se você tem o Windows 2008 R2 com ASP.NET instalado. O artigo possui orientações de como instalar no server core usando a linha de comando.
Preciso reiniciar os serviços ou dar boot no servidor?
A princípio não; o instalador irá parar os serviços necessários, aplicar o hotfix, e reiniciá-los. Note que isso pode impactar um ambiente de produção, portanto recomendamos que o mesmo seja feito de forma planejada para evitar transtornos em sistemas críticos, em horário for a do pico de uso dos sistemas. Caso por algum motivo o instalador não consiga parar os serviços, um restart será requerido.
Já apliquei as medidas de contorno (como o uso do URLScan). Preciso aplicar o hotfix assim mesmo?
Sim, a aplicação é necessária, porém você poderá fazer isso de forma mais planejada. Ainda assim, recomendamos que o mesmo ocorra o mais rapidamente possível.
Tenho outras dúvidas. O que fazer?
Se você tem um contrato de suporte Premier com a Microsoft, entre em contato com o TAM que lhe atende. Caso contrário, procure o site de suporte da Microsoft (support.microsoft.com) ou os fóruns públicos do TechNet e MSDN.

Mais uma vez, este hotfix deve ser aplicado o mais rapidamente possível.

Abraços,

Paulo.

Otimizando o tempo de carregamento do site – parte 1

Paulo Teixeira - MSFT — Tue, 28 Sep 2010 01:15:52 GMT

Quando você acessa um desses grandes portais da Internet e vê a página carregar em segundos logo acredita que isso tudo acontece porque eles tem um link com uma banda gigantesca, servidores super-poderosos, e diversos tipos de dispositivos de hardware para fazer cache, otimização e etc.

Provalvelmente tudo isso é verdade, mas mesmo assim, há algumas técnicas que são utilizadas para otimizar o tempo de carregamento das páginas de um site que estão disponíveis à sua mão.

Com isso em mente, resolvi criar alguns posts falando de algumas técnicas que você pode adotar para melhorar o desempenho do seu site. Dentre os assuntos que vou abordar merecem destaque:

paralelização de requests
utilização de compressão
redução de espaços em branco das páginas
evitar a serialização de download do javascript
otimização de tamanho das imagens
cache do lado do servidor
cache do lado do cliente

Neste post vou falar de um tópico bem simples, mas que a grande maioria dos administradores e desenvolvedores Web desconhece: Paralelização de Requests

Se você ainda usa ou lembra-se, o Internet Explorer 6.0 só “conseguia” fazer dois downloads simultâneos de uma só vez. Provavelmente você se questionou (ou reclamou veemente) sobre o porquê desta limitação absurda. Pois bem, eis aí uma novidade das velhas: O RFC2616, que define o protocolo HTTP 1.1, na seção 8.1.4 diz o seguinte:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.

Ou seja, o Internet Explorer 7 (e anteriores) simplesmente obedece o que está escrito na definição do protocolo HTTP 1.1. Porém, o mundo às vezes é dos espertos, e outros navegadores passaram a ignorar esta recomendação (Por exemplo, o Firefox abre 10 conexões simultâneas) e por isso usam melhor a banda, parecendo ser mais rápidos. (Veja http://blogs.msdn.com/b/ie/archive/2005/04/11/407189.aspx para mais detalhes sobre isso).

Com o IE8 este limite foi aumentado para 6 conexões simultâneas, mas mesmo assim ainda é um limitador. Muito bem, uma vez que isso é uma realidade, como podemos “paralelizar” o maior número de requests possíveis? Ora, com uma solução bem simples, adotada por todos os grandes portais: a divisão do site em “sub-domínios”.

Por exemplo, imagine que hoje o seu site tenha a seguinte estrutura de URLs:

- http://www.meusite.com.br
- http://www.meusite.com.br/static
- http://www.meusite.com.br/imagens
- etc…

Com essa configuração, cada cliente irá abrir de 2 até 10 (dependendo do navegador que ele use) conexões simultâneas para o seu site. Todavia, se você criar subdomínios, um para cada tipo de conteúdo, você conseguirá muito mais. Por exemplo:

- http://www.meusite.com.br/
- http://static.meusite.com.br
- http://imagens.meusite.com.br/

Com isso você conseguirá as mesmas 10 conexões simultâneas para cada domínio, mas como são três domínios diferentes, teremos 30 conexões simultâneas, o que torna a utilização da banda muito mais eficiente, e em consequência, diminui o tempo de carga das páginas.

Num próximo post vou falar sobre um recurso do IIS7.x que facilita a criação dessa nova estrutura sem ter que mudar o conteúdo do site. Fique ligado!

Um abraço e até a próxima.

Paulo

Casa nova!

Paulo Teixeira - MSFT — Tue, 28 Sep 2010 01:05:01 GMT

Pois é, resolvi mudar o endereço blog. A partir de agora os artigos estarão em http://blogs.msdn.com/b/teixeira Logo logo trago novidades… só para atiçar a curiosidade, vou começar postar em breve uns artigos com dicas rápidas para otimizar o tempo...(read more)

.NET Framework no Windows 7/Windows 2008 R2

Paulo Teixeira - MSFT — Tue, 29 Jun 2010 04:50:00 GMT

A algum tempo atrás durante um treinamento que ministrava surgiu uma dúvida sobre a compatibilidade do .NET Framework no Windows 2008 R2. Depois de muito pesquisar internamente, finalmente ficou esclarecido o que é e o que não...(read more)

Usando o Application Request Routing para migrar sites para o IIS7 - parte 4

Paulo Teixeira - MSFT — Tue, 08 Jun 2010 14:47:00 GMT

Continuando a nossa série, vamos agora para a parte mais interessante. Após a configuração do ARR com Shared Configuration e Offline Files, estamos prontos para migrar as aplicações dos servidores antigos para...(read more)

Usando o Application Request Routing para migrar sites para o IIS7 - parte 3

Paulo Teixeira - MSFT — Tue, 25 May 2010 00:34:50 GMT

Ok, no post anterior desta série nós configuramos dois servidores IIS com ARR para utilizar o recurso de configuração compartilhada (Shared Configuration). Com isso, os servidores ARR irão sempre “buscar” a sua configuração no share de rede que...(read more)

Hotfixes e patches: quanto tempo para colocar em produção?

Paulo Teixeira - MSFT — Fri, 14 May 2010 20:20:34 GMT

Uma das verificações que sempre fazemos quando estamos avaliando problemas em um servidor Web é se o mesmo está com todos os hotfixes e patches instalados (geralmente não estão). Os clientes sempre se justificam dizendo: “Não há uma regra”, ou “tenho...(read more)

Usando o Application Request Routing para migrar sites para o IIS7 - parte 2

Paulo Teixeira - MSFT — Wed, 12 May 2010 17:54:00 GMT

No meu post anterior falei como instalar o IIS e o ARR para criar uma solução que permita a migração transparente de aplicações de um ambiente “antigo” para o IIS7.x. Um ponto importante nesta configuração...(read more)

Usando o Application Request Routing para migrar sites para o IIS7 - parte 1

Paulo Teixeira - MSFT — Tue, 11 May 2010 01:33:00 GMT

Vários de nossos clientes encontram dificuldades para migrar os seus servidores e aplicações do IIS5 ou IIS6 para novos servidores baseados no IIS7.x (ou do PHP rodando no Linux/Unix para o IIS7). O grande problema é a dificuldade de homologar divervas...(read more)

Cães e gatos contra bots!

Paulo Teixeira - MSFT — Fri, 26 Oct 2007 18:27:00 GMT

Ok, não entendeu nada do título deste post, né? Desta vez vou fugir um pouco da parte técnica e mostrar uma "brincadeira" muito inteligente que encontrei no site do MS Research ( http://research.microsoft.com ). Primeiro, e...(read more)

Microsoft anuncia acesso ao código fonte do .NET Framework 3.5

Paulo Teixeira - MSFT — Wed, 03 Oct 2007 20:22:03 GMT

A Microsoft anunciou hoje que até o final do ano, juntamente com o lançamento do Visual Studio 2008, irá disponibilizar o acesso ao código-fonte do .NET Framework 3.5 sob os termos da Microsoft Shared Source Licensing . Será possível baixar o código-fonte...(read more)

Estudo de caso: ASP clássico - problemas mais comuns - Parte 01.

Paulo Teixeira - MSFT — Thu, 27 Sep 2007 04:04:17 GMT

Estive há algum tempo em um cliente que reclamava de algum processo que estava causando o uso de 100% de CPU no seu servidor SQL. Como efeito disso, uma importante aplicação Web sofria lentidão generalizada. O servidor em questão era uma máquina bem robusta...(read more)

Paulo Teixeira

Paulo Teixeira - MSFT — Mon, 10 Sep 2007 07:06:00 GMT

Olá! Este meu primeiro post é somente para fazer uma breve apresentação. Sou engenheiro de suporte na Microsoft desde 2005, e minha área de atuação é focada no servidor Web IIS (5/6/7) e também nas tecnologias relacionadas, como ASP, ASP.NET, COM+...(read more)