Web Dev & Infra: qual o seu lado?

Verificando assemblies em modo debug, v2.0 by Rafael & Henrique

2013-05-22T20:48:45Z

Conversando com dois colegas, o Rafael Marrara e o Henrique da Silva (ambos PFEs de IIS aqui comigo na Microsoft), eles comentaram que fizeram um script muito similar ao que eu havia publicado a algum tempo atrás para identificar aplicações em modo debug.

O interessante é que eles criaram esse script para resolver um pequeno “side effect” da versão inicial que eu havia escrito: o meu script carregava a DLL via powershell, e por consequência ela ficava bloqueada (durante o tempo de execução do script) não podendo sofrer nenhuma alteração.

Com isso, se a aplicação fosse recompilada naquele período de tempo, isso poderia gerar um erro. Além disso, a forma de verificar se os assemplies estão compilados em modo debug foi aperfeiçoada e dados adicionais são exibidos. O resultado final ficou muito bom e por isso eu pedi a autorização deles para publicar o script aqui no blog.

Segue:

if ($args[0] -eq $null) {
    $path = $(Split-Path $MyInvocation.InvocationName)
} else {
    if (Test-Path($args[0])) {
        $path = $args[0]
    } else {
        write-host "O diretório" $args[0] "não existe!"
        Break
    }
}

function Get-DotNetDebuggableAttribute
{
    [CmdletBinding()]
    Param(
        [Parameter(
            Mandatory=$True,
            ValueFromPipeline=$True
        )] [string[]]$files
    )

    Begin
    {
        $list = @()
    }

    Process
    {
        foreach ( $filename in $files )
        {
            if ( Test-Path $filename )
            {
                $file = Get-Item $filename
                if ( $file.Extension -eq '.dll' )
                {
                    try
                    {
                        $assembly = [System.Reflection.Assembly]::Load([System.IO.File]::ReadAllBytes($file.FullName))
                        $file | Add-Member NoteProperty ImageRuntimeVersion $assembly.ImageRuntimeVersion

                        $modules = $assembly.GetModules($false)
                        if ($modules.Length -gt 0) {
                            $portableExecutableKinds = New-Object System.Reflection.portableExecutableKinds
                            $imageFileMachine = New-Object System.Reflection.imageFileMachine
                            $modules[0].GetPEKind([ref]$portableExecutableKinds, [ref]$imageFileMachine)

$file | Add-Member NoteProperty PortableExecutableKinds $portableExecutableKinds
$file | Add-Member NoteProperty ImageFileMachine $imageFileMachine

                            Switch($portableExecutableKinds.ToString().Split(',').Trim()){
                                "Required32Bit" {$platformTarget = "x86"}
                                "PE32Plus" {$platformTarget = "x64"}
                                "ILOnly" {$platformTarget = "Any CPU"}
                                default {$platformTarget = "Unknown"}
                            }

$file | Add-Member NoteProperty PlatformTarget $platformTarget

                        } else {
                            $file | Add-Member NoteProperty PortableExecutableKinds $null
                            $file | Add-Member NoteProperty ImageFileMachine $null
                            $file | Add-Member NoteProperty PlatformTarget $null
                        }

                        $attrs = $assembly.GetCustomAttributes([System.Type]::GetType("System.Diagnostics.DebuggableAttribute"), 0)
                        if ($attrs.Count -eq 1) {
                            $attr = $attrs[0]
                            $file | Add-Member NoteProperty IsJITTrackingEnabled $attr.IsJITTrackingEnabled
                            $file | Add-Member NoteProperty IsJITOptimizerDisabled $attr.IsJITOptimizerDisabled
                        } else {
                            $file | Add-Member NoteProperty IsJITTrackingEnabled $null
                            $file | Add-Member NoteProperty IsJITOptimizerDisabled $null
                        }
                         $list += $file
                    }
                    catch
                    {
                        Write-Debug "Error trying to access the file using System.Reflection.Assembly"
                        Write-Debug "Error: $_"
                    }
                }
            }
        }
    }

    End
    {
        if ( $list.Count -gt 0 )
        {
            #Write-Output $list | Format-Table Mode, LastWriteTime, Length, Name, IsJITOptimizerDisabled, IsJITTrackingEnabled -AutoSize
            return $list
        }
    }
}

get-childitem $path -Recurse -include *.dll | Get-DotNetDebuggableAttribute | Format-Table LastWriteTime, Name, ImageRuntimeVersion, PlatformTarget, IsJITOptimizerDisabled -AutoSize

Lembrando que este script não é suportado de forma alguma pela Microsoft, use por sua conta e risco.

PS: ele não faz nenhuma alteração no seu ambiente, e portanto, não deveria causar problemas. De qualquer forma, eu recomendo utilizado em ambientes de teste, homologação ou pré-produção.

abraços,

Paulo.

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

2013-02-20T17:42:00Z

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

2013-02-18T11:25:00Z

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?

2013-02-12T23:50:00Z

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

2013-02-11T10:00:00Z

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!

2013-02-09T18:00:01Z

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+

2013-02-08T18:27:38Z

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

2011-08-05T09:26:00Z

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

2011-07-30T21:41:21Z

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

2011-05-28T21:45:19Z

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