Bem-vindo ao curso de treinamento em Windows XP Service Pack 2 para desenvolvedores.IntroduoBem-vindo ao curso de treinamento em Windows XP Service Pack 2 para desenvolvedores. O objetivo deste curso fazer com que voc, desenvolvedor, tome conhecimento das implicaes relacionadas implantao do Service Pack 2 em computadores que rodem em Windows XP Professional e Windows XP Home Edition. Especificamente, ao trmino deste curso, o aluno estar apto a: 1. Resumir as justificativas para uma maior segurana no Windows XP SP2. 2. Identificar as quatro reas de desenvolvimento afetadas por este service pack. 3. Rever a situao atual. 4. Identificar as reas comuns em que os aplicativos iro quebrar aps a implantao do XP SP2. 5. Identificar as possveis correes a curto prazo e as solues a longo prazo. 6. Explicar como os exemplos de atualizaes de aplicativos permitem que o desenvolvedor tire proveito das alteraes feitas pelo XP SP2. 7. Descrever as prximas etapas que devem ser efetuadas para corrigir os problemas que podem surgir com a instalao do XP SP2. O Windows XP Service Pack 2 mais do que um conjunto normal de correes de bug para o principal sistema operacional da Microsoft. Ele tambm est sendo usado para fornecer uma atualizao significativa que visa aprimorar a segurana do Windows XP e simplificar o processo de atualizao do software. A segurana tornou-se a principal questo para todos os usurios Windows, sejam eles corporativos ou consumidores. Os vrus tm sido um problema praticamente desde que os PCs foram lanados, mas hoje a Internet e, particularmente, a ampla disponibilidade de conexes contnuas em banda larga na rede causaram um aumento dramtico no nmero e na gravidade dos ataques. Considere os dados a seguir: Drivers de segurana

Com o nmero de incidentes em permanente ascenso, a Microsoft decidiu fazer um esforo proativo para aumentar consideravelmente a segurana das famlias de sistemas operacionais Windows XP e Windows Server 2003. Por isso, o Windows XP Service Pack 2 fornece vrios recursos novos e aprimorados, destinados ao aumento da segurana do sistema operacional e dos aplicativos.

Impacto da ferramenta para o desenvolvedorO desenvolvedor precisa estar a par de trs pontos significativos antes de aprofundar-se nos detalhes do Service Pack 2 para Windows XP.

1.

A Microsoft desenvolveu uma abordagem em 3 camadas para oferecer suporte ao SP2 nos produtos Windows .NET Framework e Visual Studio.

a.

Do Visual Studio "Whidbey" em diante, todos os produtos sero projetados para funcionar bem no XP SP2 e para permitir que os desenvolvedores tirem amplo proveito das melhorias de segurana ao usarem o Visual Studio nos prprios aplicativos e mquinas. As verses 2002 e 2003 do .NET Framework (ou seja, verses 1.0.3705 e 1.1.4322) e o Visual Studio sero reparadas conforme necessrio para permitir que os desenvolvedores tirem proveito das melhorias do XP SP2 em seus aplicativos, bem como para solucionar degradaes de funcionalidade em ferramentas significativas (se houver). Os service packs do .NET Framework que fazem uso do Execution Protection sero fornecidos no XP SP2 RTM timeframe. O Visual Studio ser reparado dentro do prazo de manuteno normal. As ferramentas lanadas antes do VS .NET 2002 no sero ajustadas para lidar com o XP SP2. Houve vrios aprimoramentos de segurana significativos no VS .NET 2002 e posterior, e a atualizao para esses produtos envolver custos extras para os desenvolvedores que no somente precisem instalar um novo conjunto de ferramentas e service pack como tambm reconstruir, testar e redistribuir os produtos. A Microsoft se esforar para assegurar que essas ferramentas continuem a funcionar corretamente no XP SP2; no entanto, possvel que essas ferramentas no se beneficiem da segurana aprimorada do XP SP2.

b.

c.

2. 3.

O .NET Framework "Whidbey" est sendo projetado para se tornar o modelo de regra de segurana para os produtos usados pelo desenvolvedor. Problemas relacionados s ferramentas afetaro o desenvolvedor em sua experincia de desenvolvimento.

Impacto no aplicativo personalizadoO Service Pack 2 introduz um conjunto de tecnologias de segurana que aumentar a capacidade de os computadores baseados em Windows XP suportarem ataques mal-intencionados por parte de vrus e worms. As tecnologias abrangem as reas a seguir.

Proteo de rede aprimorada As tecnologias de segurana includas no Service Pack 2 possibilitaro maior proteo contra ataques baseados na rede, tais como o worm MSBlaster e suas variaes. Para obter mais informaes, consulte http://www.microsoft.com/security/incident/blast.asp. Essa segurana obtida por meio de uma srie de inovaes e aprimoramentos. Agora, o Windows Firewall fica ativado por padro, e todas as portas permanecem fechadas exceto quando em uso. Houve melhorias na compatibilidade do aplicativo quando o Windows Firewall est ativo, alm de aprimoramentos na administrao corporativa (enterprise administration) do Windows Firewall (atravs de polticas de grupo - Group Policy). Foram adicionadas restries de controle de acesso (access control restrictions) infraestrutura DCOM e, atravs da execuo do servio RPC com privilgios limitados, reduziu-se a exposio de sua superfcie de ataque.

Nova proteo de memria (New Memory Protection) - Para oferecer mais proteo contra ataques que permitem copiar grandes volumes de dados para as reas de memria de um computador (buffer overruns), a Microsoft est empregando vrias tecnologias. Os componentes bsicos do Windows esto sendo recompilados com a verso mais atual da tecnologia de compilador para diminuir os buffer overruns. O trabalho continua com os fornecedores de microprocessadores, para ajudar o Windows a oferecer suporte a hardware "no execute" (NX) em microprocessadores que trabalham com o recurso. Esse recurso permite que a CPU obrigue a separao do cdigo e dos dados do aplicativo, impedindo que um componente execute um cdigo de programa que contenha um worm ou vrus na rea de memria reservada para os dados. Melhoria na segurana de Email (Improved Email Security) A Microsoft adicionou novas tecnologias de segurana de e-mail que ajudaro a impedir que os vrus (como o SoBig.F) se espalhem no e-mail e nas mensagens instantneas. Os anexos potencialmente perigosos enviados por e-mails e por mensagens instantneas sero isolados, a fim de que no possam afetar outras partes do sistema. Alm disso, as configuraes padro agora fornecem controles de anexo para o Outlook Express e Windows messenger, e a segurana e confiabilidade foram aumentadas para o Outlook Express. Aumento da segurana na navegao (Enhanced Browsing Security) - As tecnologias de segurana que foram adicionadas ao Service Pack 2 fornecem mais proteo contra contedo malicioso na Web. Duas dessas tecnologias incluem o bloqueio na zona Local Machine para impedir a execuo de scripts mal-intencionados e fortalecimento contra downloads na Web perigosos, e a incluso de um Pop-up Manager para impedir ataques de falsificaes de interface do usurio. Alm disso, as interfaces e controles de usurio foram melhoradas para ajudar a impedir a execuo de controles ActiveX e spyware nas mquinas clientes sem o conhecimento ou a permisso destes.

Juntas, essas tecnologias de segurana ajudaro a dificultar os ataques ao Windows XP, mesmo que o sistema no contenha as ltimas atualizaes ou patches instalados. Alm disso, elas so particularmente teis para reduzir os worms e vrus. Muitos clientes no conseguem ou no podem implementar os patches assim que eles so lanados. No entanto, eles ainda precisam estar protegidos contra os riscos minimizados pelos patches. Ao implantar o Service Pack 2 em computadores Windows XP, a Microsoft est entregando tecnologias de segurana que fornecem proteo adicional mesmo antes de implantar um patch. As tecnologias de segurana listadas acima consistem nas etapas seguidas pela iniciativa Trustworthy Computing para tornar os sistemas dos consumidores mais slidos. Embora muitos aplicativos no necessitem de ateno, a funcionalidade de alguns deles poder ser prejudicada pelas novas tecnologias introduzidas com o service pack. Por exemplo, o Windows Firewall permanecer ativado por padro aps a instalao do Service Pack 2. Isso, por sua vez, afetar aes como depurao remota (remote debugging) no Visual Studio e conexes de entrada e sada de aplicativos, servios e portas RPC e DCOM. O conhecimento antecipado dessas principais alteraes permitir que o desenvolvedor (juntamente com o profissional de TI) se prepare para implementar o Service Pack 2 na rede. Alm das melhorias na tecnologia de segurana, a Microsoft tambm adicionou o Improved Computer Maintenance ao SP2, o que inclui:

atualizaes automticas "silenciosas" para consumidores. download inteligente de dados de atualizao em conexes de baixa largura de banda. uma nova Security Center (Central de Segurana) para centralizar o gerenciamento de patches. melhores opes de segurana no Windows Installer. uma verso mais slida do site Microsoft's Windows Update para oferecer mais disponibilidade e resistir a ataques de negao de servio (DOS - denial-of-service).

Os usurios Enterprise podem empregar essas tecnologias para fornecer gerenciamento inteligente de patch interno. Essas alteraes afetaro principalmente os usurios e administradores de SI/TI, mas podero vir a se tornar problema para desenvolvedores de aplicativos que precisem assegurar compatibilidade com a verso revisada do Windows Installer. Para compreender melhor o significado das alteraes feitas pelo XP Service Pack 2, consulte a tabela 2. Alterao no XP SP2 Proteo de rede aprimorada Nova proteo de memria Melhoria na segurana de Email Aumento da segurana na navegao X Dev. Web X Dev. aplicativo X X X X X X X Admin. SI/TI X Usurios X

Tabela 2: implicaes decorrentes de alteraes feitas pelo XP SP2 Nas prximas sees, voc ter oportunidade de rever em detalhes as alteraes.

Proteo de rede aprimoradaCom o Windows XP Service Pack 2, a Microsoft est investindo em trs tecnologias-chave que deixaro os sistemas menos vulnerveis a ataques na rede. so elas: Windows Firewall, resties na Interface RPC e aprimoramento da segurana do DCOM.

Windows Firewall RPC Interface Restrictions DCOM Security Enhancements

Windows FirewallO Windows Firewall consiste em um firewall de filtragem stateful para Windows XP e Windows Server 2003. Ele fornece proteo para PCs conectados rede, rejeitando conexes de entrada no solicitadas atravs do TCP/IP verso 4 (IPv4). O SP2 ativa o Windows Firewall por padro e o inicializa mais cedo no processo de boot. Dentre esses novos recursos, seis podem afetar diretamente os aplicativos existentes.

Ativado por padro

Antes do SP2, o Windows XP era fornecido com o Windows Firewall desativado por padro. Os usurios precisavam executar um assistente ou navegar pela pasta Network Connections para ativar o Windows Firewall. Com o Windows Firewall ativado por padro, o computador ficar protegido dos muitos ataques baseados na rede. Se o Windows Firewall estivesse ativado por padro, o recente ataque do MSBlaster teria tido muito menos impacto, independentemente de os usurios terem patches atualizados, j que o Windows Firewall descarta comunicaes no solicitadas, tais como varredura de porta (port scanning). O Windows Firewall ativado por padro (On-by-Default) pode interferir nos aplicativos existentes se o aplicativo no funcionar com a filtragem stateful por padro. Por exemplo, se o aplicativo espera receber mensagens de outro computador sem primeiro enviar uma mensagem (isto , atue como cliente e como servidor), ele pode falhar. Alm disso, os PCs que estiverem executando um servidor Web exigiro que o Windows Firewall seja configurado para permitir essas solicitaes (http://support.microsoft.com/default.aspx?scid=kb;EN-US;320855).

Segurana no momento do boot

Nas verses anteriores do Windows, existe um intervalo de tempo entre o momento em que a pilha da rede executada e o momento em que o Windows Firewall fornece proteo. Isso possibilita que um pacote seja recebido e enviado para um servio sem a filtragem do Windows Firewall, o que expe o computador a vulnerabilidades. Isso acontece porque o driver do firewall s iniciado para filtragem depois que o servio do firewall carregado e aplica a poltica apropriada. O servio do firewall possui diversas dependncias, o que faz com que ele precise aguardar at que elas sejam liberadas para que possa aplicar a poltica no driver. Esse perodo de tempo baseado na velocidade do computador. No Windows XP Service Pack 2, o driver do firewall tem uma regra esttica, denominada poltica de tempo de boot (boot-time policy). Ela realiza a filtragem stateful e elimina o tempo de vulnerabilidade enquanto o computador est iniciando. Essa nova regra de poltica permite que o computador abra as portas para que as tarefas de rede bsicas, como DNS e DHCP, possam ser realizadas. Ela tambm permite a comunicao com um controlador de domnio para obter as polticas apropriadas. Quando o servio do firewall estiver em execuo, ele carregar (e aplicar) a poltica do Windows Firewall em tempo de execuo (run-time Windows Firewall policy) e remover os filtros do tempo de boot. (A poltica de tempo de boot no pode ser configurada.) No existe segurana de tempo de boot se a opo Windows Firewall/Internet Connection Sharing (ICS) estiver definida como Disabled.

Configurao mais fcil

Agora, o Windows Firewall mais fcil de configurar, j que permite configurar globalmente todas as interfaces de modo que as alteraes sejam aplicadas automaticamente a todas as conexes de rede novas ou j existentes. As configuraes individuais ainda podero ser realizadas. Alm disso, o Windows Firewall permite que voc crie dois conjuntos de poltica de firewall: uma para quando o computador estiver conectado rede corporativa e outra para quando no estiver. Voc pode especificar uma poltica que seja menos rgida quando o computador estiver conectado rede corporativa para permitir o funcionamento da linha de aplicativos comerciais. Voc tambm pode ter uma poltica de segurana mais agressiva, que seja reforada quando o computador deixar a rede da empresa, e que o ajude a se proteger contra ataques baseados na Internet. No entanto, os vrios perfis do Windows Firewall s se aplicam a computadores que sejam ligados a um domnio. Os computadores que pertencem a um dado grupo de trabalho (workgroup) s possuem um perfil. Os administradores podem agora usar o utilitrio de linha de comando Netsh helper (antes disponvel apenas com o Advanced Networking Pack for Windows XP) para fazer o seguinte:

o o o

Adicionar ou remover aplicativos da lista de permisses do Windows Firewall Configurar o estado padro do Windows Firewall (Off, Enabled, On com No Exceptions) Configurar quais portas devem ser abertas, incluindo se as portas permitem acesso global ou acesso restrito sub-rede local e se as portas esto abertas em todas as interfaces ou para cada interface Configurar as opes de logging Configurar as opes de tratamento de ICMP (Internet Control Message Protocol) Note que o Service Pack 2 tambm inclui novos GPOs (Group Policy Objects) para permitir que os administradores de rede gerenciem a poltica do Windows Firewall no ambiente corporativo. Esses GPOs incluem o modo Operational (On, Off, ou On with No Exceptions), Allowed Programs, Opened Ports (static), ICMP settings e Enable RPC. Eles podem ser configurados tanto nos perfis corporativos como padro.

o o

Lista de permisses de aplicativo (Windows Firewall Permissions List)

Alguns aplicativos atuam tanto como clientes de rede como servidores. Quando atuam como servidores, eles precisam autorizar que o trfego de entrada no solicitado seja recebido, j que eles

no sabem com antecedncia quem ser o parceiro (peer). Nas verses anteriores do Windows, um aplicativo precisava chamar as APIs do Windows Firewall para permitir que as portas de escuta (listening ports) necessrias fossem abertas. Isso se tornou uma dificuldade nas situaes peer-to-peer em que a porta no era conhecida com antecedncia. Cabia ao aplicativo fechar a porta novamente aps o trmino da comunicao. Sem isso, poderia haver aberturas desnecessrias no firewall se o aplicativo terminasse de forma inesperada. Alm disso, essas portas s poderiam ser abertas se os aplicativos estivessem sendo executados no contexto de segurana de um administrador local. Isso viola o princpio de privilgio reduzido, j que exige que os aplicativos sejam executados em um contexto administrativo, em vez de apenas com os privilgios mnimos necessrios. No Windows XP Service Pack 2, possvel adicionar lista de permisses do Windows Firewall um aplicativo que escute a rede, tanto de forma administrativa como programtica. Se o aplicativo estiver na lista de permisses de aplicativo (lista de permisses do Windows Firewall), o Windows abrir automaticamente a porta necessria, independentemente do contexto de segurana do aplicativo, pelo tempo em que o aplicativo estiver escutando nessas portas. O aplicativo no pode abrir nenhuma porta que no esteja usando, j que isso que pode deliberadamente ou inadvertidamente expor outro aplicativo ou servio ao trfego da rede. Isso tambm permite que os aplicativos que faam escuta de rede sejam executados como um usurio regular (em vez de como um administrador), como era o caso nas verses anteriores do Windows. Os aplicativos que no fazem escuta de rede no precisam se preocupar nem precisam ser colocados na lista de permisses do aplicativo (Application Permissions List). Se voc no precisar adicionar um aplicativo lista Firewall Permissions graficamente, o administrador poder selecionar Configure Windows Firewall no painel Network Tasks (quando estiver exibindo conexes de rede) ou por meio do boto Settings na guia Advanced de uma conexo de rede especfica. A caixa de dilogo resultante mostrada na Figura 1 permite que um administrador ative o Windows Firewall com excees (On with exceptions, isto , a lista branca est ativa), sem excees ("On with No Exceptions") ou desative-o (Off).

Figura 1: Guia General do Windows Firewall Quando a primeira opo escolhida, a lista de permisses do Windows Firewall disponvel na guia Exceptions usada de acordo com a Figura 2.

Figura 2: Guia Exceptions do Windows Firewall Para adicionar um aplicativo lista de permisses do Windows Firewall, o administrador clica no boto Add e configura o aplicativo executvel conforme mostrado na Figura 3. Note que tambm possvel ativar as portas TCP e UDP individuais nesta caixa de dilogo.

Figura 3: Caixa de dilogo Exceptions do Windows Firewall Os administradores tambm podem gerenciar a lista de permisses do Windows Firewall usando o utilitrio de linha de comando Netsh mencionado mais cedo.

Suporte a RPC

Nas verses anteriores do Windows, o Windows Firewall bloqueava a comunicao por RPC (remote procedure call). Embora o Windows Firewall possa ser configurado para autorizar o trfego da rede para o RPC Endpoint Mapper, os aplicativos que usavam endpoints dinmicas tinham o trfego RPC bloqueado pelo Windows Firewall devido escolha arbitrria de porta da rede do RPC. Muitos aplicativos e componentes falham se o RPC no est autorizado a se comunicar na rede. Alguns exemplos incluem (mas no se limitam a) o seguinte:

o o o o

Compartilhamento de arquivos e impresso Administrao remota Configurao do WMI (Remote Windows Management Instrumentation) Scripts que gerenciam clientes e servidores remotos

O RPC abre vrias portas e portanto, expe muitos servidores diferentes nestas portas. Em um tpico servidor ou estao de trabalho, existem aproximadamente 60 servidores RPC (rodando por padro) que escutam as solicitaes dos clientes na rede. Alguns servidores possuem mais, dependendo de suas configuraes. Essa a superfcie de ataque ao RPC. Pelo fato de existirem tantos servidores RPC includos no Windows XP, e como a maioria deles roda usando o mesmo nome de arquivo de imagem de processo (Svchost.exe), o Windows Firewall adota uma abordagem diferente para os servidores RPC. Ao abrir uma porta, o chamador pode reivindicar

que a porta seja para ser usada para RPC. O Windows Firewall s aceitar essa reivindicao se o chamador estiver sendo executado no sistema local (Local System), no servio de rede (Network Service) ou em contextos de segurana do servio local (Local Service security contexts). O Windows Firewall oferece suporte a uma flag de nvel (profile level flag) que permite que as portas RPC sejam abertas mesmo que o chamador no esteja na lista de permisses do Windows Firewall. Ele armazenado no registro como o valor REG _DWORD, denominado PrivilegedRpcServerPermission abaixo da profile key. Os valores correspondem enumerao NET_FWV 4_SERVICE_PERMISSION:

o o

NET_ FWV 4_SERVICE_BLOCK = 0. Os servidores RPC s estaro autorizados a abrir portas se estiverem na lista de permisses do Windows Firewall. NET_ FWV 4_SERVICE_ALLOW_LOCAL = 1. Se um servidor RPC no estiver na lista de permisses do Windows Firewall, a porta ser aberta, mas s aceitar o trfego de rede proveniente da sub-rede local. NET_ FWV 4_SERVICE_ALLOW_ALL = 2. Se um servidor RPC no estiver na lista de permisses do Windows Firewall, a porta ser aberta para o trfego de rede proveniente de qualquer sub-rede.

o

Note, no entanto, que as configuraes do aplicativo autorizado sempre substitui a configurao RPC genrica. Por exemplo, se a configurao do RPC for permitir local, mas o servidor RPC executvel tambm estiver na lista de permisses do Windows Firewall com a opo de somente sub-rede local (Local Subnet Only) definida como False, a porta do RPC ser aberta a todas as sub-redes.

On with No Exceptions

O Windows Firewall pode ser configurado para autorizar trfego de entrada no solicitado durante o uso normal. Isso geralmente ocorre porque necessrio ativar cenrios-chave, tais como compartilhamento de impressora e de arquivos. Caso seja descoberto um problema de segurana em um ou mais dos servios Windows de escuta, possvel que o computador precise mudar para o modo somente-cliente (client-only), On with No Exceptions. Alternar para esse modo somentecliente faz com que Windows Firewall bloqueie o trfego de entrada no solicitado sem precisar reconfigurar o firewall. Esse modo pode ser configurado por meio da opo On with no exceptions mostrada na Figura 1. Quando o sistema estiver nesse modo, todos os buracos estticos sero fechados. Qualquer chamada de API para abrir um buraco esttico ser autorizada e a configurao armazenada, mas ela no ser aplicada at que o modo operacional do Windows Firewall seja retornado operao normal. As solicitaes de escuta feitas pelos aplicativos tambm sero ignoradas. Lembre-se de que vrus, worms e atacantes buscam por servios para explorar. Quando est nesse modo operacional, o Windows Firewall ajuda a impedir ataques desses tipos. O computador no pode escutar as solicitaes de entrada da rede, mas as conexes de sada sero efetuadas com xito.

Firewall Implicaes para o desenvolvedorImplicaes para o desenvolvedor Para o desenvolvedor, as implicaes relacionadas s alteraes no Windows Firewall dependem do tipo de conexo utilizada pelo aplicativo. Por exemplo, conexes de sada e de entrada IPv4, conexes de entrada IPv4 para servios, e conexes de entrada IPv4 para RPC e DCOM. Conexes de sada IPv4 (Ipv4 outbound connections) Descrio

Para o consumidor tpico e computadores de escritrio, pouco trfego da rede no solicitado. O Windows Firewall considera o trfego de sada e as respostas correspondentes como sendo os componentes das conexes de sada. Todas as conexes de sada so automaticamente autorizadas pelo Windows Firewall. Para obter mais informaes sobre o que o trfego da rede do Windows Firewall permite como parte de conexes de sada TCP (Transmission Control Protocol) e UDP (User Data Protocol), consulte as observaes abaixo. Ao exigida Nenhuma. O Windows Firewall permitir automaticamente todas as conexes de sada, independentemente do programa e do contexto do usurio. Notas

Quando um computador inicia uma conexo TCP com um computador remoto, o Windows Firewall autoriza o trfego TCP somente para a porta de origem da conexo TCP a partir do endereo IP (Internet Protocol) para o qual a conexo foi iniciada. Quando um computador envia pacotes UDP, o Windows Firewall autoriza o UDP para a porta a partir da qual os pacotes UDP foram enviados a partir de qualquer endereo IP, por um perodo de 90 segundos. As respostas de Unicast ao trfego multicast e broadcast so autorizadas atravs do Windows Firewall por 500 milissegundos se forem direcionadas para a porta a partir da qual o trfego multicast foi enviado e vierem de endereos IP localizados na mesma sub-rede que o computador. Uma configurao no firewall controla esse comportamento, que ativado por padro para outro perfil do firewall.

Exemplos

Surfando na Web com o Microsoft Internet Explorer Verificando e-mails no Outlook Express Batendo papo no MSN Messenger ou no Windows Messenger

Conexes de entrada IPv4 para aplicativos (IPv4 inbound connections for applications) Descrio Este cenrio abrange um aplicativo que completa uma operao de escuta em um soquete TCP (TCP socket) ou se vincula de forma bem-sucedida a um soquete UDP atravs do Winsock. Neste cenrio, o Windows Firewall pode automaticamente abrir e fechar portas conforme solicitado pelo aplicativo. Ao exigida Quando um aplicativo que precise escutar uma porta estiver sendo instalado por um administrador, os usurios precisam indicar se desejam permitir que o aplicativo abra portas no firewall. Se o usurio consentir, o aplicativo dever usar de forma programtica o ICF API Set documentado em http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ics/ics/icf_plus_intro.asp para se autoadicionar lista de permisses de ICF. Esse conjunto de objetos COM permite que um desenvolvedor registre e configure as configuraes de perfil do ICF. O aplicativo que mostrado abaixo exibindo as informaes de configurao e usando a API fornecido neste curso. Veja a Figura 4.

Figura 4: Aplicativo Isso exigir o uso da interface COM INetFwV4AuthorizedApplication ou da classe COM NetFwV4AuthorizedApplication para adicionar o aplicativo coleo AuthorizedApplications do objeto de perfil atual por meio da interface INetFwV4Profile (marcada como Enabled). Se o usurio no consentir, o aplicativo dever usar o ICF API Set para se auto-adicionar coleo AuthorizedApplications como Disabled. Quando voc usar a interface INetFwV4AuthorizedApplication para adicionar um aplicativo coleo AuthorizedApplications, os seguintes valores sero obrigatrios:

Image File Name. Este o arquivo que chama o Winsock para ouvir o trfego da rede. Esse deve ser um caminho totalmente qualificado, mas pode conter variveis de ambiente. Friendly Name. Este o nome do aplicativo que ser mostrado aos usurios na interface de usurio do Windows Firewall.

Estes so os valores opcionais:

Local Subnet Only. Por padro, quando h uma porta aberta, todo o trfego da rede autorizado a passar por ela. Se um aplicativo precisar receber o trfego apenas de sub-rede local, por exemplo, use esse valor. Enabled. Por padro, a entrada para um aplicativo na coleo AuthorizedApplications ativada. Conforme descrito acima, esse valor deve ser usado para adicionar a entrada do aplicativo como Disabled, se o usurio no consentir na abertura de portas do aplicativo. Isso permitir que o usurio veja o aplicativo na interface de usurio do Windows Firewall e o ative mais tarde.

O ICF monitora o Winsock para ver quando o aplicativo comea e termina de escutar as portas. Como resultado, as portas sero automaticamente abertas e fechadas para os aplicativos assim que suas entradas tiverem sido ativadas na lista de permisses de ICF. Isso significa que os aplicativos Winsock no exigem nenhuma ao para abrir e fechar as portas. Cdigo de exemplo Para fins de exemplo do uso de um ICF API Set, considere um aplicativo que seja instalado por meio do Windows Installer. Um desenvolvedor que utiliza o Visual Studio .NET poderia criar um projeto de configurao que solicite atravs de um prompt que o usurio adicione o aplicativo lista de permisses de ICF e, em seguida, execute a instalao usando uma classe Installer. Para isso, seria necessrio realizar as seguintes etapas: 1. Criar uma assembly Class Library no Visual Studio .NET 2. Adicionar uma referncia NetFwV4TypeLib type library na guia COM da caixa de dilogo Add Reference, conforme mostrado abaixo. Isto criar um COM interop assembly atravs da qual o ICF API Set ser chamado pelo cdigo gerenciado. Observe que esse componente COM est instalado no Windows XP Service Pack 2. Veja a Figura 5.

Figura 5: Criando o COM interop assembly. 3. Adicione uma referncia ao assembly System.Configuration.Install.dll 4. Adicione uma classe ao projeto ICFAppListInstaller 5. Importe ou use o NetFwV4TypeLib e o namespace System.Configuration.Install da seguinte maneira:

[VB .NET] Imports System.Configuration.Install Imports NetFwV4TypeLib

[C#] using System.Configuration.Install; using NetFwV4TypeLib; 1. Adicione um cdigo classe conforme mostrado a seguir:

[VB .NET] < RunInstaller(True) > _ Public Class ICFAppListInstaller Inherits Installer

Private name, image, enabled, local As String Private appEnabled As Boolean = False Private localSubnetOnly As Boolean = True

Public Overrides Sub Uninstall(ByVal state As IDictionary) GetArgs() Dim objV4Mgr As NetFwV4MgrClass Try objV4Mgr = New NetFwV4MgrClass Catch ex As Exception ' No foi possvel instanciar; talvez o XPSP2 no esteja em execuo Context.LogMessage("Could not instantiate NetFwV4Mgrclass [" & _ ex.Message & "]") Return End Try

Try ' Remova o aplicativo da lista de permisses RemoveFromPermissionsList(image, objV4Mgr.LocalPolicy.CurrentProfile) MyBase.Uninstall(state) Catch e As Exception Context.LogMessage(e.Message) Throw New InstallException(e.Message) End Try End Sub Public Overrides Sub Install(ByVal state As IDictionary) GetArgs() MyBase.Install(state) Dim objV4Mgr As NetFwV4MgrClass Try objV4Mgr = New NetFwV4MgrClass Catch ex As Exception ' No foi possvel instanciar; talvez o XPSP2 no esteja em execuo Context.LogMessage("Could not instantiate NetFwV4Mgrclass [" & _ ex.Message & "]") Return End Try Try ' Adicione o aplicativo lista de permisses AddToPermissionsList(name, image, appEnabled, _ objV4Mgr.LocalPolicy.CurrentProfile) Catch e As Exception Context.LogMessage(e.Message) Throw New InstallException(e.Message) End Try End Sub

Private Sub GetArgs() ' Obtenha os argumentos com o instalador name = Me.Context.Parameters.Item("Name") If name = "" Then Throw New InstallException("No name specified") End If image = Me.Context.Parameters.Item("Image") If image = "" Then Throw New InstallException("No image name specified") End If enabled = Me.Context.Parameters.Item("Enabled")

Select Case enabled.ToUpper Case "1" appEnabled = True Case "0" appEnabled = False End Select local = Me.Context.Parameters.Item("LocalSubnet") Select Case local Case "1" localSubnetOnly = True Case "0" localSubnetOnly = False End Select End Sub Private Sub AddToPermissionsList(ByVal name As String, ByVal imageName As String, _ ByVal enabled As Boolean, ByVal profile As INetFwV4Profile) ' Adicione o aplicativo lista de permisses de ICF Dim app As New NetFwV4AuthorizedApplication app.Enabled = enabled app.LocalSubnetOnly = localSubnetOnly app.Name = name app.ProcessImageFileName = imageName profile.AuthorizedApplications.Add(app) End Sub Private Sub RemoveFromPermissionsList(ByVal imageName As String, _ ByVal profile As INetFwV4Profile) ' Remova o aplicativo da lista de permisses de ICF profile.AuthorizedApplications.Remove(imageName) End Sub End Class

[C#] [RunInstaller(true)] public class ICFAppListInstaller : Installer { private string name, image, enabled, local; private bool appEnabled = false; private bool localSubnetOnly = true; public override void Uninstall(IDictionary state) { GetArgs(); NetFwV4MgrClass objV4Mgr = null; try { objV4Mgr = new NetFwV4MgrClass(); } catch (Exception ex) { // No foi possvel instanciar; talvez o XPSP2 no esteja em execuo Context.LogMessage("Could not instantiate NetFwV4Mgrclass [" + ex.Message + "]"); return; } try { // Remova o aplicativo da lista de permisses RemoveFromPermissionsList(image, objV4Mgr.LocalPolicy.CurrentProfile); base.Uninstall(state); } catch (Exception e)

{ Context.LogMessage(e.Message); throw new InstallException(e.Message); } } public overrides void Install(IDictionary state) { GetArgs(); base.Install(state); NetFwV4MgrClass objV4Mgr = null; try { objV4Mgr = new NetFwV4MgrClass(); } catch (Exception ex) { // No foi possvel instanciar; talvez o XPSP2 no esteja em execuo Context.LogMessage("Could not instantiate NetFwV4Mgrclass [" + ex.Message + "]"); return; } try { // Adicione o aplicativo lista de permisses AddToPermissionsList(name, image, appEnabled, objV4Mgr.LocalPolicy.CurrentProfile); catch (Exception e) { Context.LogMessage(e.Message); throw new InstallException(e.Message); } } private void GetArgs() { // Obtenha os argumentos com o instalador name = this.Context.Parameters.Item["Name"]; if (name == "") throw new InstallException("No name specified"); image = this.Context.Parameters.Item["Image"]; if (image == "") throw new InstallException("No image name specified"); enabled = this.Context.Parameters.Item["Enabled"]; switch (enabled.ToUpper) { case "1": appEnabled = true; break; case "0": appEnabled = false; break; } local = this.Context.Parameters.Item["LocalSubnet"]; switch (local) { case "1": localSubnetOnly = true; break; case "0": localSubnetOnly = false; break; } }

private void AddToPermissionsList(string name, string imageName, bool enabled, INetFwV4Profile profile) { // Adicione o aplicativo lista de permisses de ICF NetFwV4AuthorizedApplication app = new NetFwV4AuthorizedApplication(); app.Enabled = enabled; app.LocalSubnetOnly = localSubnetOnly; app.Name = name; app.ProcessImageFileName = imageName; profile.AuthorizedApplications.Add(app); }

private void RemoveFromPermissionsList(string imageName, INetFwV4Profile profile) { // Remova o aplicativo da lista de permisses de ICF profile.AuthorizedApplications.Remove(imageName); } } Voc notar que a classe herda de Installer e faz o override dos mtodos Install e Uninstall da classe bsica. Esses mtodos sero chamados durante o processo de instalao. Ambos os mtodos declaram um objeto do tipo NetFwV4MgrClass, que usado para configurar o perfil de ICF (um objeto NetFwV4Profile) obtido por meio de uma referncia propriedade LocalPolicy.CurrentProfile. Note que, se o XPSP2 no estiver instalado na mquina de destino, o instanciamento da classe manager gerar uma exceo que ser registrada (logged), o que far com que os mtodos retornem sem executar nenhuma outra ao. O mtodo Install chama o mtodo privado AddToPermissionsList que aceita o nome amigvel (friendly name), o nome de imagem (image name), e os Booleanos (Booleans) que sero usados para ativar (enable) o aplicativo e determinar se ele deve se comunicar apenas atravs da sub-rede local. O ato de adicionar o aplicativo por si s j envolve inevitavelmente instanciar um objeto NetFwV4AuthorizedApplication, definir suas propriedades e adicion-lo coleo AuthorizedApplication do objeto de perfil (profile). Da mesma forma, o mtodo Uninstall chama o mtodo RemoveFromPermissionsList para remover o aplicativo da lista de permisses de ICF usando seu nome de imagem. Nota: O processo de importar tipos COM para o .NET e de criar uma assembly interop cria uma classe gerenciada (managed) para cada co-classe anexada Class. por isso que o cdigo gerenciado mostrado usa o tipo NetFwV4MgrClass no lugar de simplesmente NetFwV4Mgr. 7. Crie um projeto Windows Setup no Visual Studio .NET e adicione-o a mesma soluo. 8. Adicione a sada ou assembly produzida pelo projeto Class Library ao Application Folder, usando o File System Editor 9. No User Interface Editor, adicione uma caixa de dilogo Checkboxes aps a caixa de dilogo Welcome e antes da caixa de dilogo Installation Folder. 10. Configure as propriedades da caixa de dilogo na janela de propriedades, usando a seguinte tabela: Propriedade BannerText Valor Configurao ICF (Internet Connection Firewall)

BodyText

Este aplicativo aceita solicitaes de rede de entrada. Para fazer isso, ele precisa receber permisses no Internet Connection Firewall se o seu computador estiver executando Windows XP Service Pack 2. Permite que este aplicativo aceite solicitaes de entrada de rede. CHECKBOXA1 No marcado True Permite comunicao apenas na sub-rede local CHECKBOXA2 Marcado True

CheckBox1Label CheckBox1Property CheckBox1Value CheckBox1Visible CheckBox1Label CheckBox1Property CheckBox1Value CheckBox1Visible

Tabela 3: Propriedades da caixa de dilogo 11. Defina as checkboxes remanescentes como invisveis (invisible) 12. No Custom Actions Editor, clique com o boto direito e adicione uma ao personalizada (custom action). Selecione a sada de projeto (project output) da assembly da class library ou a assembly propriamente dita que voc adicionou anteriormente ao projeto. Clique em Ok. Isso adiciona aes para cada um dos quatro eventos, conforme mostrado abaixo. Veja a Figura 6.

Figura 6: Aes para eventos. 13. Na janela Properties, defina a propriedade CustomActionData de cada uma das aes para a string: /Name="My Custom App" /Image="[TARGETDIR] myapp.exe" /Enabled="[CHECKBOXA1]" /LocalSubnet="[CHECKBOXA2]" Nota: Os quatro argumentos so lidos no mtodo private GetArgs da classe installer anteriormente mostrada. O projeto Installer fornece os valores para as propriedades [TARGETDIR], [CHECKBOXA1] e [CHECKBOXA2]. A classe ICFAppListInstaller usa esses valores para passar ao mtodo AddToPermissionsList os parmetros apropriados. 14. Crie a soluo para construir tanto o projeto de instalao como o de configurao (installer e setup project). 15. Clique com o boto direito do mouse no projeto de setup e selecione Install. A instalao deve agora ser executada e a caixa de dilogo mostrada abaixo, na Figura 7, pedir ao usurio que adicione o aplicativo lista de permisses. Observe que se a caixa de seleo no estiver marcada, o aplicativo ser adicionado lista de permisses mas ser desativado.

Figura 7: Caixa de dilogo para adicionar o aplicativo lista de permisses. 16. Abra a janela Network Connection e, no painel esquerdo, clique em Configure Internet Connection Firewall. Selecione a guia Exceptions para visualizar as excees, conforme mostradas na Figura 8 abaixo.

Figura 8: Exceptions Notas

O aplicativo precisa estar sendo executado no contexto do usurio com direitos de Administrator para que possa se auto-adicionar lista de permisses do Windows Firewall. As portas sero automaticamente abertas e fechadas para os aplicativos na lista de permisses do Windows Firewall, independentemente do contexto de usurio no qual os aplicativos estiverem rodando. Os aplicativos precisam obter o consentimento do usurio antes de se auto-adicionarem coleo AuthorizedApplications. Svchost.exe no pode ser adicionado coleo AuthorizedApplications.

Exemplos

Usando udio e vdeo no MSN Messenger ou no Windows Messenger Transferindo arquivos no MSN Messenger ou no Windows Messenger Hospedando um jogo de vrios participantes Usando Remote Assistance

Conexes de entrada IPv4 para servios (IPv4 inbound connections for services)

Descrio Embora os desenvolvedores sejam cautelosos em usar as APIs AuthorizedApplication para todos os outros cenrios, o uso da API Global Port do Windows Firewall recomendado para servios que escutam em portas fixas. Como essas portas estaro sempre abertas, no h muita vantagem em abri-las dinamicamente. Em vez disso, os usurios ganham a capacidade de personalizar as configuraes do firewall para essas portas fixas quando as APIs Global Port so usadas. Ao exigida Quando um servio precisa escutar em uma porta fixa, ele precisa tambm perguntar ao usurio se pode permitir o servio em abrir as portas no firewall. Se o usurio consentir, o servio poder usar a interface COM INetFwV4OpenPort para adicionar regras ao perfil do Windows Firewall, usando a coleo GloballyOpenPorts para abrir a porta fixa ou portas exigidas pelo servio. Essas regras devero estar ativadas. Se o usurio no consentir, o servio ainda dever usar a interface COM INetFwV4OpenPort para adicionar regras ao Windows Firewall para abrir a porta fixa ou as portas exigidas pelo servio. Essas regras, entretanto, no devero estar ativadas, para que um administrador possa facilmente ativ-las posteriormente. Quando voc usar a interface INetFwV4OpenPort para adicionar uma abertura de porta ao Windows Firewall, sero necessrios os seguintes valores:

Port. Este o nmero da porta a ser aberta. Ele deve estar entre 1 e 65.536, inclusive. Friendly Name. Este o nome da abertura de porta que ser mostrado aos usurios na interface de usurio do Windows Firewall. Estes so os valores opcionais:

Protocol. Este valor usado para especificar se a porta a ser aberta TCP ou UDP. Caso no seja especificado, ser presumido TCP. Local Subnet Only. Por padro, todo o trfego da rede autorizado quando a porta est aberta. Este valor pode ser usado para restringir a porta, para que somente o trfego da sub-rede local seja autorizado atravs do Windows Firewall. Ao abrir uma porta, o servio deve restringir a porta ao trfego da sub-rede local, sempre que possvel. Enabled. Por padro, a abertura de porta ativada assim que ela adicionada. Conforme descrito acima, se o usurio no consentir na abertura de portas do servio, esse valor deve ser usado para adicionar a abertura de porta como Disabled. Isso permitir que o usurio veja o servio na interface de usurio do Windows Firewall e o ative mais tarde. Quando um servio desativado, ele deve novamente usar a interface INetFwV4OpenPort para fechar as portas estticas que abriu (sempre que possvel). Isso pode ser feito facilmente se for o nico servio que usa as portas. No entanto, se o servio compartilhar as portas com outros servios, ele no dever fech-las a no ser que possa confirmar que elas no estejam sendo usadas por nenhum dos outros servios.

Cdigo de exemplo Como um exemplo do uso dessa funcionalidade, considere os dois mtodos mostrados na listagem de cdigo abaixo. Esses mtodos seriam includos em um assembly de class library ou dentro de um aplicativo, e exigiriam que a biblioteca de tipos COM NetFwV4TypeLib fosse referenciada no projeto.

[VB .NET] Private Function AddPort(ByVal enabled As Boolean, ByVal localOnly As Boolean, _ ByVal name As String, ByVal port As Integer, _ ByVal protocol As NET_FWV4_IP_PROTOCOL_) As Boolean ' Adicione a porta lista de permisses de ICF Dim icfMgr As NetFwV4MgrClass Try icfMgr = New NetFwV4MgrClass Catch ex As Exception ' XPSP2 no instalado Return False End Try Try Dim profile As INetFwV4Profile Dim portClass As New NetFwV4OpenPortClass ' Obtenha o perfil atual profile = icfMgr.LocalPolicy.CurrentProfile ' Defina as propriedades de porta portClass.Enabled = enabled portClass.LocalSubnetOnly = localOnly portClass.Name = name portClass.Port = port portClass.Protocol = protocol ' Adicione a porta lista de permisses de ICF profile.GloballyOpenPorts.Add(portClass) Return True Catch ex As Exception ' Registre o erro ou avise o usurio Return False End Try End Function

Private Function RemovePort(ByVal port As Integer, _ ByVal protocol As NET_FWV4_IP_PROTOCOL_) As Boolean ' Remova a porta de acordo com a lista de permisses de ICF Dim icfMgr As NetFwV4MgrClass Try icfMgr = New NetFwV4MgrClass Catch ex As Exception ' XPSP2 no instalado Return False End Try Try Dim profile As INetFwV4Profile ' Obtenha o perfil atual profile = icfMgr.LocalPolicy.CurrentProfile ' Remova a porta de acordo com a lista de permisses de ICF profile.GloballyOpenPorts.Remove(port, protocol) Return True Catch ex As Exception ' Registre o erro ou avise o usurio Return False End Try End Function [C#]

private bool AddPort(bool enabled, bool localOnly, string name, int port, NET_FWV4_IP_PROTOCOL_ protocol) { // Adicione a porta lista de permisses de ICF NetFwV4MgrClass icfMgr = null; try { icfMgr = new NetFwV4MgrClass(); } catch (Exception ex) { // XPSP2 no instalado return false; } try { INetFwV4Profile profile; NetFwV4OpenPortClass portClass = new NetFwV4OpenPortClass(); // Obtenha o perfil atual profile = icfMgr.LocalPolicy.CurrentProfile; // Defina as propriedades de porta portClass.Enabled = enabled; portClass.LocalSubnetOnly = localOnly; portClass.Name = name; portClass.Port = port; portClass.Protocol = protocol; // Adicione a porta lista de permisses de ICF profile.GloballyOpenPorts.Add(portClass); return true; catch (Exception ex) { // Registre o erro ou avise o usurio return false; } }

private bool RemovePort(int port, NET_FWV4_IP_PROTOCOL_ protocol) { // Remova a porta de acordo com a lista de permisses de ICF NetFwV4MgrClass icfMgr = null; try { icfMgr = new NetFwV4MgrClass(); } catch (Exception ex) { // XPSP2 no instalado return false; } try { INetFwV4Profile profile; // Obtenha o perfil atual profile = icfMgr.LocalPolicy.CurrentProfile; // Remova a porta de acordo com a lista de permisses de ICF

profile.GloballyOpenPorts.Remove(port, protocol); return true; } catch (Exception ex) { // Registre o erro ou avise o usurio return false; } } O mtodo AddPort aceita os argumentos que podem ser usados para adicionar uma porta lista de permisses de ICF. Observe que o objeto NetFwV4MgrClass usado para obter o perfil atual e ir gerar uma exceo se o XPSP2 no estiver instalado na mquina. O objeto NetFwV4OpenPortClass ento instanciado e suas propriedades so preenchidas com os argumentos. O objeto ento adicionado coleo GloballyOpenPorts do perfil. O mtodo RemovePort mais simples, j que s precisa passar a porta e o protocolo para o mtodo Remove da coleo GloballyOpenPorts. Um aplicativo pode usar o mtodo AddPort conforme mostrado aqui.

[VB .NET] If MessageBox.Show( _ "Would you like to allow this application to listen on a fixed port?", _ "ICF Configuration", MessageBoxButtons.YesNo, MessageBoxIcon.Question, _ MessageBoxDefaultButton.Button2) = DialogResult.Yes Then If Not AddPort(True, False, "MyCustomPort", 3283, _ NET_FWV4_IP_PROTOCOL_.NET_FWV4_IP_PROTOCOL_TCP) Then MessageBox.Show( _ "The port could not be added. See the error log for details", _ "ICF Configuration", MessageBoxButtons.OK, MessageBoxIcon.Error) End If End If [C#] if (MessageBox.Show( "Would you like to allow this application to listen on a fixed port?", "ICF Configuration", MessageBoxButtons.YesNo, MessageBoxIcon.Question, MessageBoxDefaultButton.Button2) == DialogResult.Yes) { if (!AddPort(true, false, "MyCustomPort", 3283, NET_FWV4_IP_PROTOCOL_.NET_FWV4_IP_PROTOCOL_TCP)) MessageBox.Show( "The port could not be added. See the error log for details", "ICF Configuration", MessageBoxButtons.OK, MessageBoxIcon.Error); } Uma vez executado, o aplicativo emitir um prompt de confirmao ao usurio (veja a Figura 9).

Figura 9: Prompt de usurio. Adicione a porta conforme indicado na caixa de dilogo. A Figura 10 exibe as informaes.

Figura 10: Adicionando a porta para excees. Notas

O aplicativo precisa estar sendo executado no contexto do usurio com direitos de Administrator para que possa abrir portas estaticamente no Windows Firewall. Ao abrir estaticamente as portas atravs da API INetFwV4, o servio deve se limitar ao trfego da sub-rede local, sempre que possvel. Os servios precisam obter o consentimento do usurio antes de abrir as portas estaticamente no Windows Firewall. O servio no deve nunca abrir as portas automaticamente sem primeiro avisar o usurio. Quando o compartilhamento de arquivos e de impressora for ativado, quatro portas sero especificamente afetadas pela restrio de sub-rede local. As seguintes portas recebero trfego apenas da sub-rede local.

o o o o

UDP porta 137 UDP porta 138 TCP porta 139 TCP porta 445 Se um aplicativo ou servio tambm usar essas portas, ele s poder se comunicar com outros ns na sub-rede local.

Exemplos

Compartilhamento de arquivos e de impressora UpnP (Universal Plug and Play) Desktop remoto

Conexes de entrada IPv4 em portas RPC e DCOM (IPv4 inbound connections on RPC and DCOM ports) Descrio Alguns aplicativos e servios exigem o uso de portas RPC seja atravs de DCOM ou de RPC para conexes de entrada. Devido aos impactos significativos na segurana resultantes da abertura de portas RPC, essas portas so tratadas como um caso especial, e os desenvolvedores s devero tentar ativar o RPC pelo Windows Firewall quando for absolutamente necessrio. Ao exigida O Windows Firewall inclui uma configurao explcita no firewall para ativar a abertura e o fechamento automticos das portas para o RPC de cada perfil. Sendo assim, os aplicativos e servios no precisam abrir portas especficas para usar o RPC para conexes de entrada. No entanto, por padro o RPC ser bloqueado pelo Windows Firewall. Isso significa que um aplicativo ou servio precisa autorizar as portas RPC no Windows Firewall durante o processo de instalao. possvel que alguns aplicativos mais antigos precisem ser configurados manualmente. Se as portas RPC j estiverem autorizadas, o aplicativo ou servio no precisar fazer nada para funcionar corretamente. Se o usurio consentir na autorizao de portas RPC, o aplicativo ou servio dever usar a interface COM INetFwV4Profile para definir AllowRpcPorts como TRUE, a fim de autorizar o trfego sobre as portas RPC. Se o usurio no concordar com a autorizao para portas RPC, o aplicativo ou servio no dever configurar o Windows Firewall para o uso de portas RPC.

Cdigo de exemplo Como um exemplo da definio dessa propriedade, considere o mtodo mostrado na listagem de cdigo abaixo. O mtodo SetAllowRpc aceita um valor booleano e o utiliza para definir a propriedade AllowRpcPorts do perfil ICF corrente. Repare que este fragmento de cdigo presume que NetFwV4TypeLib tenha sido referenciado no projeto VS .NET e na assembly interop criada.

[VB .NET] Private Function SetAllowRpc(ByVal enabled As Boolean) As Boolean ' Defina AllowRpcPorts Dim objV4Mgr As NetFwV4MgrClass Try

objV4Mgr = New NetFwV4MgrClass Catch ex As Exception ' XPSP2 no instalado Return False End Try objV4Mgr.LocalPolicy.CurrentProfile.AllowRpcPorts = enabled Return True End Function

[C#] private bool SetAllowRpc(bool enabled) { // Defina AllowRpcPorts NetFwV4MgrClass objV4Mgr = null; try { objV4Mgr = new NetFwV4MgrClass(); } Catch (Exception ex) { // XPSP2 no instalado return false; } objV4Mgr.LocalPolicy.CurrentProfile.AllowRpcPorts = enabled; return true; } Notas necessrio que o aplicativo ou servio esteja rodando no contexto de um usurio com direitos de Administrator para que se possa ativar ou desativar a abertura automtica de portas RPC no Windows Firewall. O aplicativo ou servio dever obter o consentimento do usurio antes de autorizar o uso de portas RPC no Windows Firewall. O aplicativo ou servio s deve tentar autorizar as portas RPC atravs do Windows Firewall quando for absolutamente necessrio. A definio das portas RPC s funcionar para servidores RPC que rodem no contexto de sistema local (Local System), servio de rede (Network Service) ou de servio local (Local Service). Portas abertas por servidores RPC que sejam executados em outros contextos de usurio no sero ativadas por meio dessa configurao. Em vez disso, esses servidores RPC devem usar a lista de permisses do Windows Firewall.

Restries da interface RPCForam feitas vrias alteraes no servio RPC (Remote Procedure Call) do Windows XP Service Pack 2 que ajudam a tornar as interfaces RPC mais seguras por padro bem como reduzem o risco de ataques de superfcie do Windows XP. A mudana mais significativa consiste na incluso da chave de registro RestrictRemoteClients . Essa chave modifica o comportamento de todas as interfaces RPC no sistema e visa, por padro, eliminar acessos annimos remotos s interfaces RPC do sistema, com algumas excees. A mudanas adicionais incluem a chave de registro EnableAuthEpResolution e trs novas flags de registro de interface. Com essa nova funcionalidade no Service Pack 2, muito mais difcil atacar um computador atravs de uma interface RPC, j que a autenticao simples obrigatria por padro. Esse um alvio particularmente til

contra worms que contam com buffer overruns explorveis que podem ser chamadas remotamente atravs de conexes annimas.

RestrictRemoteClientsChave de registro RestrictRemoteClients (\\HKLM\SOFTWARE\Policies\Microsoft\Windows NT\RPC\) Quando uma interface registrada por meio da API RpcServerRegisterIfExor RpcServerRegisterIf2, o RPC permite que o aplicativo do servidor restrinja o acesso interface, geralmente atravs de uma callback de segurana. A chave de registro RestrictRemoteClients fora o RPC a realizar verificaes adicionais de segurana para todas as interfaces, mesmo que a interface no possua nenhuma callback de segurana registrada. A chave de registro RestrictRemoteClients pode ter os trs valores descritos abaixo. Se a chave no estiver presente, equivalente a ter o valor RPC_ Restrict_Remote_Client_Default.

O valor RPC_RESTRICT_REMOTE_CLIENT_NONE (0) faz com que o sistema ignore a nova restrio interface RPC. O aplicativo do servidor totalmente responsvel por impor as restries de RPC apropriadas. Essa configurao equivalente ao comportamento nas verses anteriores do Windows. O valor RPC_RESTRICT_REMOTE_CLIENT_DEFAULT (1) o valor padro no Windows XP Service Pack 2. Esse valor restringe o acesso a todas as interfaces RPC. Todas as chamadas annimas remotas so rejeitadas pelo runtime do RPC. Se uma interface registra uma callback de segurana e fornece o sinalizador (flag) RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, essa restrio no se aplicar a ela. O valor RPC_RESTRICT_REMOTE_CLIENT_HIGH (2) o mesmo que o valor RPC_RESTRICT_REMOTE_CLIENT_DEFAULT; a diferena que o sinalizador RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH no far com que a interface seja dispensada da restrio. Com esse valor, um sistema no pode receber chamadas annimas remotas usando o RPC.

RestrictRemoteClients Implicaes para o desenvolvedorDescrio Se o aplicativo RPC espera receber chamadas de clientes RPC annimos remotos, essa mudana poder quebrar a aplicao. Ao exigida Existem trs opes para reparar esses problemas. Elas esto listadas por ordem de preferncia.

Exija que seus clientes RPC usem segurana do RPC quando contatarem o aplicativo servidor. Esse o melhor mtodo de reduzir ameaas de segurana. Faa com que sua interface seja dispensada de requerer autenticao, definindo a flag RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH durante o registro da interface por meio de RpcServerRegisterIf2 ou de RpcServerRegisterIfEx. Isso configura o RPC para autorizar conexes annimas apenas para a interface de seu aplicativo.

Obrigue o RPC a exibir o mesmo comportamento das verses anteriores do Windows definindo a chave de registro RestrictRemoteClients como RPC_RESTRICT_REMOTE_CLIENT_NONE (0). O RPC ir ento aceitar conexes annimas para todas as interfaces. Essa opo dever ser evitada sempre que possvel, j que reduz a segurana geral do computador.

Notas

Os clients RPC que usam a seqncia de protocolo named pipe (ncacn_np) esto isentos de todas as restries discutidas nesta seo. Devido aos diversos e significativos problemas de compatibilidade retroativa, no possvel restringir a seqncia de protocolo named pipe por padro.

EnableAuthEpResolutionChave de registro EnableAuthEpResolution (\\HKLM\SOFTWARE\Policies\Microsoft\Windows NT\RPC) Uma interface RPC que seja remotamente e anonimamente acessvel e que seja registrada por padro no Windows XP apresenta uma superfcie de ataque significativa. O RPC propriamente dito precisa registrar essa interface para fornecer uma resoluo de endpoint (endpoint resolution) para as chamadas que usam endpoints dinmicos. Com a incluso da chave de registro RestrictRemoteClients, por padro, a interface RPC Endpoint Mapper no pode ser acessada anonimamente. Essa uma melhoria de segurana significativa, mas ela muda o processo de soluo de um endpoint. Atualmente, qualquer cliente RPC que tente fazer uma chamada usando um endpoint dinmico dever primeiro consultar o RPC Endpoint Mapper no servidor para determinar qual endpoint ele deve se conectar. Essa consulta realizada anonimamente, mesmo que o cliente RPC propriamente dito seja executado com segurana RPC. As chamadas annimas para a interface RPC Endpoint Mapper falharo por padro no Windows XP Service Pack 2 devido ao valor padro da nova chave RestrictRemoteClients. Isso torna necessrio modificar o runtime do cliente RPC para executar uma consulta autenticada ao Endpoint Mapper. Se a chave EnableAuthEpResolution estiver definida no cliente, o runtime do cliente RPC usar o NTLM para autenticar o Endpoint Mapper. Essa consulta autenticada s ser realizada se a chamada do cliente RPC real usar autenticao.

EnableAuthEpResolution Implicaes para o desenvolvedorDescrio Essa alterao exigida para habilitar um cliente RPC a fazer uma chamada para um servidor RPC que tenha registrado um endpoint dinmico em um sistema Windows XP Service Pack 2. O computador cliente precisa definir esta chave de registro para que possa executar uma consulta autenticada ao RPC Endpoint Mapper. Essa chave no quebra nada. Ela usada para ativar o cenrio especfico descrito mais cedo. Quando essa chave ativada, todas as consultas ao RPC Endpoint Mapper que forem realizadas em favor das chamadas de autenticao sero realizadas por meio de autenticao NTLM. Ao exigida Nenhuma. Consulte a descrio acima.

Novas flags de registro de interface RPC (RPC Interface Registration Flags)Foram criadas trs novas flags de registro de interface, que facilitam ao desenvolvedor de aplicativo proteger a interface RPC.

RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH Quando essa flag estiver registrada, o runtime do RPC invocar o callback de segurana registrada para todas as chamadas, independentemente de todas as configuraes de segurana da chamada. Sem essa flag, o RPC rejeitar todas as chamadas no autenticadas antes de elas alcanarem o callback de segurana. Essa flag s funcionar quando houver um callback de segurana registrado.

RPC_IF_SEC_NO_CACHE Um callback de segurana registrado para uma interface de modo a restringir o acesso a ela. Um callback de segurana tpico personifica (impersonates) o cliente para determinar se ele possui direitos suficientes para fazer uma chamada para a interface. Se a identidade de um cliente em particular passar um callback de segurana uma vez, ela geralmente passar o mesmo callback de segurana todas as outras vezes. O runtime do RPC tira proveito desse padro lembrando-se de quando a identidade de um cliente individual passou um callback de segurana e ignora o callback de segurana das chamadas subseqentes feitas por esse cliente para a mesma interface. Esse recurso chamado security callback caching e existe desde o Windows 2000. No caso do Windows XP Service Pack 2, voc pode usar a flag RPC_IF_ SEC _NO_CACHE para desativar o caching do callback de segurana para uma determinada interface. Isso til no caso da verificao de segurana precisar mudar, possivelmente rejeitando uma identidade de cliente que tenha sido anteriormente autorizada.

RPC_IF_LOCAL_ONLY Quando uma interface registrada com essa flag, o RPC rejeita as chamadas feitas pelos clientes RPC remotos. Alm disso, as chamadas locais feitas sobre todas as seqncias de protocolo ncadg_* e ncacn_* (exceto para named pipes, usando ncacn_np) tambm sero rejeitadas. Se uma chamada for feita em ncacn_np, o RPC s a autorizar se ela no vier do SVR, que filtra todas as chamadas remotas. As chamadas Ncalrpc so sempre autorizadas.

Novas flags de registro de interface do RPC Implicaes para o desenvolvedorImplicaes para o desenvolvedor Essa mudana oferece aos desenvolvedores de aplicativos RPC ferramentas de segurana adicionais para ajud-los a proteger melhor sua interface RPC. Essas flags no alteraro nem quebraro nenhum aplicativo Windows XP existente. Seu uso ficar a critrio do desenvolvedor.

Aprimoramentos de segurana no DCOMO COM (Component Object Model) da Microsoft um sistema orientado a objetos, distribudo e independente de plataforma, destinado criao de componentes de software binrios que podem interagir entre si. O DCOM (Distributed Component Object Model) permite que os aplicativos sejam distribudos entre os locais mais relevantes a voc e ao aplicativo. O protocolo de conexo DCOM oferece suporte de forma transparente, visando comunicao confivel e eficiente entre os componentes COM.

Se voc s fizer uso do COM para os componentes COM in-process, esta seo no se aplicar ao seu caso. Esse recurso s ser indicado ao seu caso se voc tiver um aplicativo servidor COM que atenda a um dos seguintes critrios:

A permisso de acesso do aplicativo menos rgida do que a necessria para execut-lo. Geralmente, o aplicativo ativado em um computador que execute Microsoft Windows XP por um cliente COM remoto, sem o uso de uma conta administrativa. Por padro, o aplicativo usa callbacks remotos no autenticados em um computador que execute Windows XP. O aplicativo s se destina ao uso local. Isso significa que voc pode restringir o seu aplicativo servidor COM para que ele no possa ser acessado remotamente.

Vrias mudanas foram feitas no COM. Para saber mais, clique no item de seu interesse

Computer-wide Restrictions Granular COM Permissions

Restries no mbito do computador (Computer-wide Restrictions)Foi feita uma alterao no COM para fornecer controles de acesso no mbito do computador, os quais governam o acesso a todas as solicitaes de chamada, inicializao ou ativao no computador. A maneira mais simples de considerar esses controles de acesso como uma chamada AccessCheck adicional que feita em relao a uma lista de controle de acesso no mbito do computador (ACL - access control list) em cada chamada, ativao ou inicializao de qualquer servidor COM no computador. Se o AccessCheck falhar, a solicitao de chamada, ativao ou inicializao ser negada. Isso ocorrer juntamente com qualquer AccessCheck que seja executado em relao a ACLs especficas ao servidor. Como conseqncia, ele fornece uma barreira de autorizao mnima que precisa ser passada para acessar os servidores COM no computador. Haver uma ACL no mbito do computador para inicializar permisses que abranjam ativao e inicializao, bem como uma ACL no mbito do computador para permisses de acesso que abranjam chamadas. Elas podem ser configuradas por meio de programao ou atravs da console MMC (Component Services Microsoft Management Console). Para configurar essa opo a partir da interface do usurio, o administrador deve abrir o gerenciador de Component Services e selecionar Properties no menu de contexto do computador a ser configurado. Ser exibida a caixa de dilogo mostrada na Figura 11, e a segurana dever ser configurada na guia COM Security.

Figura 11: My Computer Properties, COM Security Essas ACLs no mbito do computador oferecem uma maneira de substituir (override) configuraes de segurana fracas especificadas por um aplicativo atravs do CoInitializeSecurity ou de configuraes de segurana especficas ao aplicativo. Isso fornece um padro de segurana mnimo a ser passado, independentemente das configuraes do servidor especfico. Essas ACLs so verificadas quando as interfaces expostas pelo RPCSS (pacote de gerenciamento de memria) so acessadas. Isso oferece um mtodo para controlar quem tem acesso a esse servio de sistema. Essas ACLs disponibilizam um local centralizado, onde um administrador pode definir uma poltica de autorizao comum que se aplique a todos os servidores COM no computador. Por padro, as configuraes de restrio do computador Windows XP so: Permisso Inicializao (Launch) Administrador Local (Launch) Local Activate Remote (Launch) Remote Activate Todos Local (Launch) Local Activate Annimo

Acesso (Access)

Local (Call) Remote (Call)

Local (Call)

Tabela 4: Configuraes de restrio em computador Windows XP

Muitos aplicativos COM incluem algum cdigo especfico segurana (por exemplo, chamar CoInitializeSecurity), mas usam configuraes muito fracas, que freqentemente permitem acesso no autorizado ao processo. Atualmente, no existe nenhuma maneira de um administrador alterar essas configuraes para uma segurana mais forte nas verses anteriores do Windows. A infra-estrutura do COM inclui o pacote de gerenciamento de memria RpcSs, um servio de sistema que executado durante a inicializao do sistema aps ser adicionado mquina. Ele gerencia a ativao de objetos COM e a tabela de objetos em execuo, e fornece servios auxiliares ao DCOM remoto. Ele expe as interfaces RPC que podem ser chamadas remotamente. Como alguns dos servidores COM permitem acesso remoto no autenticado (conforme explicado na seo anterior), essas interfaces podem ser chamadas por qualquer pessoa, inclusive por usurios no autenticados. Como resultado, os RpcSs podem ser atacados por qualquer usurio mal-intencionado, atravs de computadores remotos no autenticados. Nas verses anteriores do Windows, no havia nenhuma maneira de o administrador compreender o nvel de exposio dos servidores COM em um computador. Para ter uma idia do nvel de exposio, o administrador precisava verificar sistematicamente as opes de segurana configuradas para todos os aplicativos COM registrados no computador, mas, como existem aproximadamente 150 servidores COM em uma instalao padro do Windows XP, essa tarefa desencorajadora. No existe nenhuma maneira de ver as configuraes de um servidor que incorpore segurana no software, exceto revendo o cdigo-fonte daquele software. As restries no mbito do computador do DCOM minimizam esses trs problemas. Elas tambm permitem que o administrador desative a ativao, a inicializao e as chamadas DCOM de entrada.

Restries no mbito do computador implicaes para o desenvolvedorDescrio Por padro, qualquer pessoa, atravs de um grupo Todos (Everyone), recebe permisses para inicializao local, ativao local e chamadas locais. Isso deveria permitir que todos os cenrios locais funcionassem sem modificao no software ou no sistema operacional. Por padro, todos recebem permisses de chamada remota. Isso permite muitos cenrios de clientes COM, inclusive o caso comum onde um cliente COM passa uma referncia local a um servidor remoto, transformando um cliente em um servidor. Isso talvez desabilite cenrios que requeiram chamadas remotas no autenticadas. Da mesma forma, por padro, somente os administradores recebem permisses de inicializao e ativao remotas. Isso inabilita ativaes remotas por parte de no-administradores nos servidores COM instalados. Ao exigida Como resultado, se voc implementar um servidor COM e esperar oferecer suporte ativao remota por parte de um cliente COM no administrativo, ou esperar oferecer suporte a chamadas no autenticadas remotas, melhor reavaliar se essa a melhor configurao. Nesse caso, voc precisar alterar a configurao padro desse recurso. Essas ACLs so armazenadas no registro (registry) em:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction= ACL HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction= ACL

Este um valor nomeado que definido como um tipo REG _BINARY; ele contm dados que descrevem a ACL dos principals que podem acessar qualquer classe ou objeto COM no computador. Os direitos de acesso na ACL so: COM_RIGHTS_EXECUTE 1 COM_RIGHTS_EXECUTE_LOCAL 2 COM_RIGHTS_EXECUTE_REMOTE 4 COM_RIGHTS_ACTIVATE_LOCAL 8 COM_RIGHTS_ACTIVATE_REMOTE 16 Essas ACLs podem ser criadas por meio de funes de segurana normais. Somente os usurios com direitos de Administrador podero modificar essas configuraes.

Permisses COM granulares (Granular COM Permissions)Essa alterao diferencia os direitos de acesso do COM com base no espao. Os dois espaos definidos so Local e Remote. Uma mensagem COM Local chega por meio do protocolo LRPC, enquanto a mensagem COM Remote chega por meio de um protocolo de transporte de host de uma RPC (remote procedure call), tais como o TCP (transmission control protocol). Por esse motivo, as permisses de chamada e de ativao esto sendo separadas para refletir os dois espaos definidos. Alm disso, as permisses de ativao esto sendo movidas da Access Permission ACL para a Launch Permission ACL. Como a ativao e a inicializao esto ambas relacionadas com a obteno de um ponteiro de interface, os direitos de acesso de inicializao e ativao logicamente devem ficar juntos em uma ACL. E, como voc sempre especifica permisses de inicializao atravs de configurao (se comparado s permisses de acesso (Access Permissions), que so freqentemente especificadas por programao), colocar a permisso de ativao na Launch Permission ACL dar ao administrador controle sobre a ativao. As Launch Permission ACLs so divididas em quatro direitos de acesso:

Local Launch (LL) Remote Launch (RL) Local Activate (LA) Remote Activate (RA)

O descritor de segurana de permisses de acesso (Access Permission security descriptor) est dividido em dois tipos de direitos de acesso:

Local Calls (LC) Remote Calls (RC)

Essa segurana COM permite que o administrador aplique configuraes de segurana bastante especficas. Por exemplo, voc pode configurar um servidor COM para que ele aceite chamadas locais de qualquer pessoa mas s aceite chamadas remotas dos administradores. A interface de usurio para configurar essas opes de segurana especficas mostrada na Figura 12.

Figura 12: Opes de segurana para objetos COM Depois que o administrador selecionar Customize em Launch and Activate Permissions, bastar clicar no boto Edit para exibir a caixa de dilogo mostrada na Figura 13.

Figura 13: Caixa de dilogo Launch Permissions

Essas distines podem ser especificadas atravs de alteraes nos descritores de segurana de permisses do COM. As verses mais antigas do aplicativo servidor COM no tm como restringir um aplicativo para que ele s possa ser usado localmente sem ser exposto na rede por meio do DCOM . Quando os usurios tm acesso a um aplicativo servidor COM, eles tm acesso tanto ao uso local como remoto. Um aplicativo servidor COM pode querer se expor a usurios no autenticados para implementar um cenrio de callback do COM. Neste cenrio, o aplicativo deve expor tambm sua ativao aos usurios no autenticados, o que pode no ser desejado. Permisses COM precisas do ao administrador flexibilidade para controlar a poltica de permisso COM do computador. Essas permisses habilitam a segurana para os cenrios especificados. Como resultado, a Tabela 5 mostrada abaixo representa as configuraes que foram adicionadas ou alteradas no Windows XP Service Pack 2. Nome da configurao Localizao Valor padro anterior (se aplicvel) Valor padro Valores possveis ACL

MachineLaunchRestriction

HKLM\SOFTWARE\ Everyone = LL,LA,RL,RA Microsoft\Ole\ Anonymous = LL,LA,RL,RA (Esta uma nova chave de registro. Com base no comportamento existente, esses sero os valores efetivos.) HKLM\SOFTWARE\ Everyone = LC, RC Anonymous = LC, RC Microsoft\Ole\ (Esta uma nova chave de registro. Com base no comportamento existente, esses sero os valores efetivos.)

Administrator = LL,LA,RL,RA Everyone = LL,LA

MachineAccessRestriction

ACL Everyone = Local, Remote. Anonymous = Local

ActivationFailureLoggingLevel HKLM\SOFTWARE\ 0 Microsoft\Ole\

0

0-2

CallFailureLoggingLevel

HKLM\SOFTWARE\ N/A Microsoft\Ole\

2

1,2

InvalidSecurityDescriptor LoggingLevel

HKLM\SOFTWARE\ N/A Microsoft\Ole\

1

1,2

Tabela 5: Incluses e/ou alteraes no Windows XP Service Pack 2

Permisses COM granulares Implicaes para o desenvolvedor

A incluso de mais permisses granulares para o servidor COM traz vrias implicaes para os desenvolvedores com relao compatibilidade retroativa. Descrio Para oferecer compatibilidade retroativa, os descritores de segurana do COM existentes so interpretados para autorizar ou negar acesso local e remoto simultaneamente. Ou seja, uma entrada de controle de acesso (ACE - access control entry) ir autorizar o acesso local e remoto ou neg-los. No existem problemas de compatibilidade retroativa com relao a direitos de inicializao ou de chamadas. Existem, no entanto, problemas de compatibilidade com relao aos direitos de ativao. Se, nos descritores de segurana existentes para um servidor COM, as permisses de inicializao configuradas forem mais restritivas do que as permisses de acesso e do que o mnimo necessrio para os cenrios de ativao do cliente, ento a Launch Permissions ACL dever ser modificada para que fornea as permisses apropriadas aos clientes autorizados. No caso de aplicativos COM que utilizam as opes de segurana padro, no h problemas de compatibilidade. No caso de aplicativos iniciados dinamicamente por meio da ativao COM, a maioria no ter problemas de compatibilidade, j que as permisses de inicializao j devero incluir qualquer um que seja capaz de ativar um objeto. Se essas permisses no estiverem configuradas corretamente, poder haver falhas de ativao aleatrias quando os chamadores sem permisso de ativao tentarem ativar um objeto quando o servidor COM no estiver em execuo. Os aplicativos que merecem mais ateno com relao a problemas de compatibilidade so os aplicativos COM que j tiverem sido inicializados por meio de outro mecanismo, como o Windows Explorer ou o Service Control Manager. Voc tambm pode iniciar esses aplicativos por meio de uma ativao COM anterior, que substitui as permisses de inicializao de acesso padro e especifica as permisses de inicializao que forem mais restritivas do que as permisses de chamada. Se um sistema que foi atualizado para o Windows XP Service Pack 2 for retornado a um service pack mais antigo, qualquer entrada de controle de acesso que tenha sido editada para permitir acesso local, acesso remoto, ou ambos, ser interpretada para autorizar acesso local e remoto. Qualquer ACE que tenha sido editada para negar acesso local, acesso remoto, ou ambos, ser interpretada para negar tanto acesso local como remoto. Voc deve assegurar que todos as ACEs sejam verificadas sempre que for desinstalar um service pack. Ao exigida Se voc implementar um servidor COM e substituir as configuraes de segurana padro, assegure-se de que a Launch Permissions ACL especfica ao aplicativo conceda permisso de ativao aos usurios apropriados. Se ela no conceder, voc precisar alterar a permisso de inicializao especfica ao aplicativo para dar os direitos de ativao aos usurios apropriados. As permisses de inicializao especficas ao aplicativo so armazenadas no registro. Para obter mais informaes, consulte http://go.microsoft.com/fwlink/?LinkId=20924. As ACLs COM podem ser criadas ou modificadas por meio de funes de segurana normais.

Nova proteo de memriaCom o Windows XP Service Pack 2, a Microsoft est introduzindo proteo de execuo (Execution Protection) para dar mais proteo contra o mau uso do espao de memria. Leia mais sobre Execution Protection

Proteo de execuo (Execution Protection)A proteo de execuo (tambm conhecida como NX, ou no execute) impede a execuo do cdigo a partir de pginas de dados, tais como a heap padro, diversas pilhas e pools de memria. A proteo pode ser aplicada tanto no modo usurio como no modo kernel. Ela tambm fora os desenvolvedores a marcar explicitamente as pginas como executveis antes de executar o cdigo das pginas de dados. Isso promove boa engenharia de software e melhores prticas para os desenvolvedores de aplicativos e drivers. A proteo de execuo consiste em um recurso do sistema operacional que conta com o hardware do processador para marcar a memria com um atributo que indique que o cdigo no deve ser executado a partir daquela memria. A proteo de execuo funciona com base na pgina de memria virtual, muito freqentemente alterando um bit na entrada da tabela da pgina (PTE) para marcar a pgina de memria. A implementao da proteo de execuo no hardware, bem como a marcao da pgina de memria virtual, variam de acordo com a arquitetura do processador. No entanto, os processadores que oferecem suporte proteo de execuo so capazes de gerar uma exceo quando o cdigo for executado a partir de uma pgina marcada com o conjunto de atributos apropriado. A verso de 32 bits do Windows atualmente utiliza o recurso de processador no-execute page protections conforme definido pela AMD (Advanced Micro Devices). Esse recurso requer que o processador seja executado no modo PAE (Physical Address Extension). Embora as nicas famlias de processadores que oferecem suporte a hardware compatvel com Windows para execuo de proteo sejam a AMD K8 e os processadores Itanium da Intel, espera-se que os futuros processadores de 32 e 64 bits forneam proteo de execuo. A Microsoft est se preparando para isso e encoraja essa tendncia oferecendo suporte proteo de execuo em seus sistemas operacionais Windows. Os desenvolvedores de drivers e aplicativos devem estar familiarizados com a proteo de execuo e com os requisitos do software em execuo na plataforma de suporte. Os aplicativos que utilizam gerao de cdigo JIT (just-in-time) ou que executam memria a partir da heap ou da pilha de processos padro devem prestar especial ateno aos requisitos de proteo de execuo (Execution Protection). Os desenvolvedores de drivers so encorajados a conhecer o modo PAE nas plataformas que oferecem suporte proteo de execuo. O comportamento do modo PAE nos sistemas Windows com menos de 4 gigabytes (GB) de espao de endereo fsico foi alterado para minimizar as incompatibilidades de driver. A Microsoft est oferecendo suporte a processadores emergentes que incorporam proteo de execuo, por meio de acrscimos no Windows (comeando pelo Microsoft Windows XP Service Pack 2). A proteo de execuo tem vantagens bvias com relao a explorao de buffer overrun e promove boas prticas de codificao gerais para desenvolvedores para Microsoft e outros desenvolvedores. Dois tipos de funcionalidade foram adicionados neste service pack.

Proteo de execuo em verses de 64 bits do Windows As verses de 64 bits do Windows que esto alojadas em processadores de 64 bits podem executar programas de aplicativos no modo 64 bits, tambm chamado modo nativo. Independentemente da arquitetura do processador, a proteo de execuo no modo kernel das verses de 64 bits do Windows aplicada pilha (stack), ao paged pool e ao session pool (pool de sesso). A proteo de execuo ativada por padro no Windows XP Service Pack 2, e no h maneiras de desativ-la. Os aplicativos de 64 bits no devem executar cdigo a partir da pilha ou na heap de processo padro. Os aplicativos que desejam alocar a memria executvel devem faz-lo usando o VirtualAlloc() com um dos atributos de memria PAGE_EXECUTE.

Proteo de execuo em verses de 32 bits do Windows e aplicativos Essa funcionalidade tem dois modos.

o

Proteo de execuo de modo de usurio Espera-se que em breve muitos computadores que executam aplicativos Windows ou compatveis com Windows usaro processadores de 32 bits que executem verses de 32 bits do Windows. No entanto, novos processadores como o AMD Opteron e Athlon-64 suportam ambos os modos operacionais de 32 e 64 bits (legado e nativo, respectivamente). Esses processadores combinados de 32 e 64 bits so capazes de rodar em um ambiente legado puro (sistema operacional de 32 bits com aplicativos de 32 bits) e podem usufruir da proteo de execuo quando o modo PAE est habilitado. A Microsoft est estudando mtodos de desativar ou ativar a proteo de execuo por aplicativo (nos aplicativos de 32 bits). Os aplicativos de 64 bits devem funcionar com a proteo de execuo ativada por padro. Uma exceo na proteo de execuo resultar no cdigo de status STATUS_ACCESS_VIOLATION (0xc0000005) nos sistemas Windows. Na maioria dos processos, ela ser uma exceo no tratada, que causar a interrupo do processo.

o

Proteo de execuo do modo Kernel A proteo de execuo funciona de forma semelhante tanto no modo de usurio como no modo kernel. A proteo de execuo para regies da memria no modo kernel no poder ser ativada ou desativada de acordo com o driver. Nas verses de 32 bits do Windows, a proteo de execuo s aplicada por padro pilha (stack). Observe que isso difere das verses de 64 bits do Windows, onde a pilha, o paged pool e o session pool (pool de sesso) tm a proteo de execuo aplicada. Uma violao de acesso de proteo de execuo no modo kernel resultar em um Bugcheck 0xFC: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY.

Proteo de execuo Implicaes para o desenvolvedorEstas alteraes podem atingir duas reas de compatibilidade que afetaro diretamente o desenvolvedor. Compatibilidade do aplicativo Descrio previsvel que o comportamento de alguns aplicativos seja incompatvel com a proteo de execuo. Aplicativos que executam gerao de cdigo dinmico (tais como gerao de cdigo JIT - Just-In-Time) que no marcam explicitamente o cdigo gerado com direito de permisso Execute podem ter problemas de compatibilidade com a proteo de execuo. Por exemplo, os aplicativos Windows .NET Framework atualmente no marcam o cdigo gerado com permisses Execute. O XPSP2 reconhece as verses atuais do .NET Framework e as executa com o NX desativado (off). Desse modo, os aplicativos .NET existentes ainda continuaro a ser executados. A Microsoft est aprimorando o .NET Framework para tirar proveito do NX e fornecer service packs para cada verso lanada no XP SP2 RTM timeframe. O .NET Framework "Whidbey" ir oferecer suporte nativo a NX. Os desenvolvedores de aplicativo podero encontrar aplicativos que quebram quando o NX est ativado. Se isso ocorrer, o desenvolvedor ou administrador do sistema poder aplicar um patch, um fragmento de cdigo que inserido em uma pilha de chamadas ou numa cadeia de cdigos. O problema geralmente ocorre em um contexto no gerenciado, e no foi previsto originalmente. O fragmento de dados adicionado ao aplicativo por meio do ACT (Application Compatibility Toolkit). Um novo fragmento de dados, a instruo Disable NX, includo no ACT para desativar o Data Execution Prevention para um aplicativo, permitindo que este seja executado apropriadamente. Para obter mais informaes sobre o Application Compatibility Toolkit, consulte http://www.microsoft.com/windows/appcompatibility/default.mspx. Ao exigida

Os aplicativos que tentarem violar a proteo de execuo recebero uma exceo com o cdigo de status STATUS_ACCESS_VIOLATION (0xC0000005). Se um aplicativo necessitar de memria executvel, ele deve definir explicitamente esse atributo na memria apropriada, especificando PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE ou PAGE_EXECUTE_WRITECOPY no argumento de proteo de memria das funes de alocao da memria virtual.

LPVOID VirtualAlloc( LPVOID lpAddress, SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect);Compatibilidade do driver Descrio Os problemas de compatibilidade de driver relacionados proteo de execuo so geralmente centrados nos problemas de compatibilidade induzida do modo PAE. Por si s, a proteo de execuo pode criar problemas de compatibilidade com drivers que executem gerao de cdigo ou que utilizem outras tcnicas para gerar cdigo executvel em tempo real. O suporte proteo de execuo estar sempre ativado em drivers que so carregados em verses de 64 bits do Windows. Embora muitos drivers que criam cdigo executvel foram reparados no Windows XP Service Pack 2, no h garantia de que todos tenham sido atualizados. No entanto, como existem poucos drivers que empregam essas tcnicas, no se espera que a proteo de execuo sozinha causar uma grande quantidade de problemas de compatibilidade de driver. O principal problema de compatibilidade de driver diz respeito execuo do modo PAE (Physical Address Extension) nos sistemas de 32 bits. Alguns drivers podem falhar no carregamento se o PAE estiver ativado porque o dispositivo pode no ser capaz de executar endereamento de 64 bits ou pode assumir que o modo PAE requer mais de 4 GB de RAM. Esses drivers partem do princpio de que recebero sempre endereos de 64 bits quando no modo PAE e que eles (ou seus dispositivos) so incapazes de interpretar o endereo. Outros drivers carregam no modo PAE mas podem causar instabilidade no sistema ao modificarem diretamente entradas de tabela de pgina (PTEs) do sistema. Esses drivers esperam PTEs de 32 bits, mas em vez disso, recebem PTEs de 64 bits no modo PAE. O maior problema de compatibilidade de driver PAE envolve transferncias de DMA (direct memory access) e alocao de registro de mapa. Muitos dispositivos que suportam DMA, geralmente adaptadores de 32 bits, no so capazes de executar endereamento fsico de 64 bits. Quando executado no modo 32 bits, o dispositivo pode alocar todo o espao de endereo fsico. No modo PAE, possvel que os dados estejam presentes em um endereo fsico maior que 4 GB. Para permitir que os dispositivos com essas limitaes funcionem neste cenrio, o Windows XP Service Pack 2 fornece um buffer duplo para a transao DMA, disponibilizando um endereo de 32 bits indicado por um registro de mapa (map register). O dispositivo pode executar a transao DMA para o endereo de 32 bits, e o kernel copia a memria no endereo de 64 bits fornecido ao driver. Quando esse sistema executado com o PAE desativado, os drivers de dispositivos de 32 bits nunca requerem que seus registros de mapa sejam apoiados pela memria real. Isso significa que o buffer duplo no necessrio, j que todos os dispositivos e drivers esto dentro do espao de endereo de 32 bits. Com base nos testes de drivers para dispositivos de 32 bits em computadores baseados em x86 e x64, presumese que muitos drivers compatveis com DMA, testados no cliente esperam registros de mapa ilimitados. Para restringir os problemas de compatibilidade, o Windows XP Service Pack 2 incluiu alteraes na camada de abstrao de hardware (HAL) que imitam o comportamento do 32-bit HAL DMA. A HAL alterada concede registros de mapa ilimitados quando o sistema est rodando no modo PAE. Alm disso, o gerenciador de memria do kernel ignora qualquer endereo fsico acima de 4 GB.

Como resultado dessas alteraes na HAL e no gerenciador de memria, o impacto na compatibilidade do driver do dispositivo dever ser mnimo nos sistemas compatveis com NX que executem Windows XP Service Pack 2. Ao exigida Os aplicativos que requerem regies executveis de memria devem usar os atributos PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE ou PAGE_EXECUTE_WRITECOPY ao alocar a memria. Alm disso, os aplicativos no podem ser executados a partir da pilha (stack) ou heap de processo padro (default process heap). A maioria dos aplicativos que executa aes incompatveis com a proteo de execuo precisar ser atualizada para ser compatvel. Se um aplicativo alocar memria executvel a partir de uma heap dedicada, ele dever assegurar que a flag EXECUTE esteja definida na memria heap. Ele pode usar a API VirtualAlloc para alocar a memria com as configuraes de proteo apropriadas. Se um aplicativo no alocar a memria executvel a partir de uma heap dedicada, ele precisar ser alterado para que possa faz-lo. O aplicativo precisar criar essa heap usando a API VirtualAlloc, e precisar ao menos especificar a flag EXECUTE para essa memria. Qualquer cdigo gerado dever ser colocado dentro dessa heap executvel. Uma vez gerado o cdigo executvel, recomenda-se que o aplicativo defina protees de memria para desautorizar o acesso WRITE heap por intermdio da API VirtualProtect. Isso fornecer proteo adicional para as regies executveis do espao de endereo do processo.

LPVOID lpvBase = VirtualAlloc( NULL, // dwSize, // MEM_RESERVE, // PAGE_EXECUTE_READWRITE); // /* Altere a proteo de pgina VirtualProtect (lpStack, dwSize, PAGE_READONLY, lpdwOldProt);

sistema seleciona endereo tamanho da alocao alocar pginas reservadas acesso Execute, Read, Write para read only. */

Segurana de e-mail aprimoradaAs pessoas compartilham informaes e colaboram entre si trocando arquivos em seus computadores. Elas enviam arquivos por e-mail, na forma de anexos. Alm disso, transferem arquivos atravs de clientes de bate-papo (chat) em tempo real e baixam arquivos na Internet. Com o uso cada vez maior das redes em banda larga, as pessoas tm ainda mais facilidade para trocar arquivos. Infelizmente, os hackers utilizam esses mesmos mecanismos para fazer com que seus softwares mal-intencionados se proliferem com rapidez. Eles enganam os usurios, colocando cargas malignas em arquivos benignos (como vrus de macros) ou anexando arquivos infectados a mensagens de e-mail. Para aumentar a proteo de usurio, muitos aplicativos bloqueiam tipos de arquivo "perigosos" especficos, usando um esquema personalizado ou recorrendo API AssocIsDangerous fornecida no Windows XP Service Pack 1 ou no Windows Server 2003, e emitem avisos poderosos para os tipos de arquivos considerados menos perigosos. Esse modelo de comportamento oferece vrios problemas. Primeiro, os usurios so obrigados a tomar decises de confiabilidade em relao aos anexos, o que abre a probabilidade de eles falharem ao fazer distino entre vrus e anexos seguros. Isso acontece porque os usurios tomam decises de confiabilidade com base em convenes sociais, em vez de por compreenso tcnica. Em segundo lugar, impossvel criar uma lista completa de todos os tipos de arquivo e classific-los de forma precisa com segurana, porque a extenso nem sempre o determinante final do tipo (como nos documentos XML ou MIME sniffing) e porque este um modelo inerentemente reagente,