Publicado em: 12 de Janeiro de 2005

por Steve Riley
Gerente de Programas Sênior, Unidade de Tecnologia e Negócios de Segurança
Veja outras colunas sobre Gerenciamento de Segurança.
No mês passado introduzi a vocês ao IPsec, uma tecnologia maravilhosa, porém desconcertante às vezes. Agora que você compreende o que é e como funciona, este mês eu gostaria de destacar a habilidade do IPSec para ajudar a resolver três problemas comuns de segurança.
| Usando o IPsec para bloquear worms | |
| Usando o IPsec para proteger servidores | |
| Usando o IPsec para isolar o domínio | |
| Tecnologia de Virar a Cabeça | |
| Saiba mais |
Pode parecer condescendente, mas a melhor maneira de bloquear worms é não deixá-los entrar! Ah, porque muitas pessoas não entendem, ou mesmo tentam entender mais sobre as ameaças e riscos associados com e-mails e navegação na web, já que worms e outros tipos de códigos maliciosos são simplesmente fatos da vida. Dito isso, como podemos reduzir os estragos causados por estes códigos?
Você pode evitar códigos maliciosos de três maneiras diferentes:
| • | Prevenir que o código se instale |
| • | Prevenir que o código seja executado |
| • | Prevenir que o código se comunique |
A maneira mais difícil é prevenir que o código se instale. Apesar dos firewalls dos hosts e das utilidades de rastreamento de vírus e spywares conseguirem de bloquear alguns códigos maliciosos, a responsabilidade de permitir que o código se instale ou não freqüentemente recai sobre os usuários. Alguns recursos do Microsoft Windows XP Service Pack 2 criam barreiras adicionais contra códigos maliciosos mas elas ainda assim dependem que os usuários deixem os recursos habilitados (o que é feito por padrão) ou tomem as decisões certas quando o sistema operacional mostrar os prompts. Mas é possível eliminar algumas destas decisões configurando muitos dos recursos através da Política de Grupo e não permitindo que usuários comuns executem como se fossem administradores locais.
As SRPs (software restriction policies - políticas de restrição de software) ajudam a prevenir que códigos maliciosos sejam executados. Usando a Política de Grupo, é possível aplicar restrições a um computador que permitirão apenas que programas autorizados sejam executados. Resista à tentação de pensar em outra direção - isto é, permitir que tudo seja executado, exceto o que é ruim. Como você pode saber com certeza tudo o que ruim? Se você combinar uma lista de permissão de uma organização mundial com usuários administradores não-locais, você tem um ambiente no qual os códigos maliciosos que conseguem chegar no computador serão incapazes de fazer qualquer coisa perigosa - o SRP simplesmente não irá permitir que seja executado. Eu sou fã dos SRPs e aconselho-o a estudar o uso deles em sua organização. Para ajudá-lo, inclui alguns links no final deste artigo.
Em algumas instancias, sua única opção seria prevenir que os códigos maliciosos se comuniquem. As políticas do IPsec irão ajudá-lo a limitar quais tipos de tráfego serão aceitos num computador, e quais tipos de tráfego um computador irá gerar. As regras com ações de filtragem que especificam simplesmente para bloquear ou permitir trafego - isto é, criar associações de segurança - e podem criar filtros eficientes de pacotes básicos em computadores individuais. Você pode usar a Política de Grupo para designar estas regras para os computadores e reduzir a quantidade de tráfego malicioso propagando em sua rede.
A escolha das políticas do IPsec depende dos sistemas operacionais que estão sendo executados. Os sistemas operacionais do Windows XP ou do Windows Server 2003 incluem firewalls baseados no host que são mais eficientes do que o IPsec para o bloqueio do tráfego no sentindo interno, portanto suas políticas do IPsec bloqueariam apenas o tráfego de saída. O Windows 2000 não inclui um firewall baseado no host, portanto deve-se considerar políticas do IPsec que bloqueiem o tráfego tanto no sentido interno quanto externo.
Considere o worm "Slammer". O Slammer buscava computadores executando o SQL Server ou o MSDE e portanto estaria ouvindo na porta 1434 UDP. A atualização de todos os computadores leva algum tempo, e por isso uma mitigação temporária excelente é o uso da Política de Grupo para designar rapidamente uma política do IPsec para todos os computadores para que bloqueiem o tráfego de entrada na porta vulnerável. Para prevenir que um computador seja infectado pelo Slammer, você pode designar uma porta que bloqueie todo o tráfego de entrada de qualquer lugar para o próprio endereço de IP do computador com porta destino 1434/UDP:
| • | Lista de filtros com um filtro: from any-address:any-port to my-address:1434/udp |
| • | Ação do filtro: bloquear |
| • | Regra: conectar a lista à ação; todas as interfaces; sem túnel; qualquer método de autenticação (tanto faz já que não há associação de segurança do IPsec aqui) |
Você também pode fazer scripts de políticas do IPsec usando ferramentas de linha de comando. Existem ferramentas diferentes que podem ser usadas dependendo de seu sistema operacional. Para o Windows 2000, a ferramenta é ipsecpol.exe do Resource Kit; para o Windows XP, é a ipseccmd.exe da pasta de ferramentas de suporte no CD-ROM ou através de download; para o Windows Server 2003, é a netsh ipsec incluída com o sistema operacional (veja o final deste artigo para links). Você pode aplicar o filtro do Slammer no Windows 2000 com este comando:
ipsecpol -w REG -p "Block UDP 1434 Filter" -r "Block Inbound UDP 1434 Rule" -f *=0:1434:UDP -n BLOCK -x
(No Windows XP o comando é ipseccmd com a mesma sintaxe.) Este comando cria e designa uma política estática chamada "Block UDP 1434 Filter" com uma única regra chamada "Block Inbound UDP 1434 Rule" (Regra de Bloqueio de Tráfego de entrada da UDP 1434) contendo a mesma lista de filtragem acima conectada ao uma ação de filtragem de "bloqueio". Políticas estáticas são armazenadas no registro e persistirão entre re-iniciações. A política não será aplicada até próxima iniciação ou reinício do agente da política do IPsec. Se você quer que a política seja aplicada imediatamente o seu script deve também parar e começar o serviço chamado "policyagent" (agente de políticas).
Caso um computador seja infectado com o Slammer, você pode usar uma regra diferente do IPsec para prevenir que o computador infecte outros computadores bloqueando as comunicações no sentido externo para a destinação porta 1434/UDP:
| • | Lista de filtros com um filtro: from my-address:any-port to any-address:1434/udp |
| • | Ação do filtro: bloquear |
| • | Regra: conectar a lista à ação; todas as interfaces; sem túnel; qualquer método de autenticação (tanto faz já que não há associação de segurança do IPsec aqui) |
Note a diferença sutil aqui: na primeira regra a lista de filtros é from any-address:any-port to my-address:1434/udp (de qualquer-enderço:qualquer-porta para meu-endereço: 1434/udp); na segunda regra a lista de filtros é from my-address:any-port to any-address:1434/udp (do meu-endereço:qualquer-porta para qualquer-endereço: 1434/udp). A segunda regra bloqueia qualquer tráfego de saída destinado à porta 1434 UDP de qualquer computador. Use este comando para fazer o script daquela regra e o adicione à mesma política do primeiro:
ipsecpol -w REG -p "Block UDP 1434 Filter" -r "Block Outbound UDP 1434 Rule" -f 0=*:1434:UDP -n BLOCK
Omita o "-x" aqui já que o comando está adicionando outra regra à política já existente.
Você também pode usar as utilidades de linha de comando para aplicar políticas dinâmicas - estas continuam fazendo efeito apenas enquanto o sistema está sendo executado. Elas são perdidas se o agente da política ou o computador for reiniciado. Estes dois comandos criarão uma política dinâmica que faz o mesmo que a política estática acima:
ipsecpol -f[*=0:1434:UDP]
ipsecpol -f[0=*:1434:UDP]
Os colchetes em volta da especificação do filtro indicam que este é o tráfego que o mecanismo da política deveria bloquear.
Até agora estivemos explorando como usar o IPsec para bloquear o tráfego de entrada e externo de destinos "ruins". Você pode ser ainda mais restritivo com as políticas do IPsec e bloquear todos os tráfegos, e então criar regras que permitam certos tráfegos em certos locais. É preciso pensar cuidadosamente sobre quais tipos de tráfego devem ser permitidos e onde, planejar detalhadamente, e testar intensivamente suas idéias antes de lançá-las para a produção. Esteja preparado para falhas no começo!
Um bom uso para uma política "bloquear-tudo-exceto" é a proteção de servidores. Imagine que você esteja construindo um servidor da web. Porque este servidor deveria aceitar qualquer trafego de entrada que não seja trafego da web, pelo menos na sua conexão do lado da Internet (se for dual-homed, ou seja, se pertencer a duas redes diferentes)? Você pode usar uma política do IPsec para construir um filtro de pacotes básico que descartará tudo exceto o que faz sentido para o propósito de seus servidores - num servidor da web, por exemplo, tudo exceto o trafego destinado à porta 80 TCP (e 443 se algumas páginas utilizarem HTTPS).
Tais políticas economizam o tempo dos testes e implantações de atualizações. Se alguém descobrir uma vulnerabilidade no sistema operacional mas uma política do IPsec não permitir o acesso ao serviço vulnerável, é possível implantar estas políticas para permitir que você tenha tempo adicional para testar e implantar atualizações de acordo com a sua programação de parada.
Vamos continuar com o exemplo do servidor da web. A sua política do IPsec teria duas regras:
Regra n°. 1
| • | Lista de filtros com um filtro: from any-address:any-port to my-address:any-port |
| • | Ação do filtro: bloquear |
| • | Regra: conectar a lista à ação; todas as interfaces; sem túnel; qualquer método de autenticação (tanto faz já que não há associação de segurança do IPsec aqui) |
Regra n°. 2
| • | Lista de filtros com um filtro: from any-address:any-port to my-address:80/tcp and from any-address:any-port to my-address:443/tcp |
| • | Ação do filtro: permitir |
| • | Regra: conectar a lista à ação; todas as interfaces; sem túnel; qualquer método de autenticação (tanto faz já que não há associação de segurança do IPsec aqui) |
Para fazer o script disto, use os seguintes comandos:
ipsecpol -w REG -p "Allow Web Traffic" -r "Block Everything" -f *+0 -n BLOCK -x
ipsecpol -w REG -p "Allow Web Traffic" -r "Permit Inbound TCP 80" -f *+0:80:TCP -f *+0:443:TCP -n PASS
Note nestes exemplos que um "+" substitui o "=" entre as especificações da fonte e do destino endereço/porta/protocolo. Isto diz para o agente da política para criar regras "espelho" que são necessárias para que o tráfego de resposta deixe o servidor da web. Sem o espelho, seriam necessárias regras separadas que permitissem o tráfego de saída das portas 80 e 443 do servidor. Quando criamos regras no GUI elas são espelhadas automaticamente.
Pense sobre a função dos diversos servidores em sua organização e comece a desenvolver políticas do IPsec que são apropriadas para estas funções. Use a Política de Grupo para designar políticas do IPsec baseadas em unidades organizacionais que reflitam cada função. Estas políticas podem ajudar a aumentar significativamente a segurança de seu ambiente ao implementar um método para limitar o tráfego que pode adentrar um servidor.
Se você está usando o Active Directory, você sabe quem são os usuários: eles precisam autenticar quando querem usar os recursos da rede. Mas e os computadores? É claro que alguns dos computadores fazem parte do seu domínio. No entanto, a arquitetura do Windows não exige. Desde que um usuário tenha credenciais válidas, ele ou ela pode acessar os recursos da rede de qualquer computador da rede. E o gerente de credenciais do Windows XP facilita ainda mais sua vida com um computador que não faz parte do domínio!
O conceito de "isolamento do domínio" está cada vez mais popular. Nós começamos a falar sobre ele no final de 2001; agora está sendo executado em toda a rede corporativa da Microsoft e nas redes de muitos usuários. Se você ainda não havia considerado este conceito, nós o encorajamos a pensar a respeito. No final deste artigo você encontrará um link para um guia mais detalhado baseado na nossa implantação.
O isolamento do domínio é importante por muitas razoes. Os computadores que fazem parte do domínio são computadores confiáveis, pelo menos de certa forma, porque você pode tirar vantagem de coisas como a Política de Grupo, modelos de segurança, configurações de restrição de software, políticas do IPsec, Microsoft Systems Management Server (SMS), e outras tecnologias relacionadas com segurança que você pode controlar e gerenciar de forma centralizada. Os computadores cuja configuração você pode controlar são computadores que fazem apenas o que você permite que façam. Estes computadores serão muito menos perigosos em seu ambiente do que máquinas perigosas não gerenciadas, sobre as quais você não tem nenhum conhecimento acerca da existência ou das configurações.
Aqui você está na verdade dizendo que nenhum usuário pode criar uma máquina perigosa e acessar os recursos do domínio - apenas computadores autorizados podem se comunicar com outros computadores autorizados. É mais fácil do que você imagina implementar isto em todo o seu domínio. Primeiro adicione esta política do IPsec à sua Política de Grupo padrão do domínio:
| • | Lista de Filtros: use a lista de filtros existente no exemplo All IP Traffic |
| • | Ação do Filtro: apenas ESP, encriptação nula, integridade SHA-1; requer segurança; não se comunica com máquinas sem IPsec |
| • | Regra: conectar a lista à ação; todas as interfaces; sem túnel; autenticação Kerberos; sem resposta padrão |
Você pode usar AH ao invés de ESP nulo mas sua política não funcionaria com dispositivos que precisam comunicar através de tradutores de endereços de rede. Você também precisa criar uma regra que dispense os seus controladores de domínio porque você precisa se comunicar com eles para autenticar e conseguir o ticket Kerberos que é usado para todas aos outras comunicações:
| • | Lista de Filtros: filtros com o endereço ou extensões de endereços de seus controladores de domínio |
| • | Ação do Filtro: permitir |
| • | Regra: conectar a lista à ação; todas as interfaces; sem túnel; qualquer método de autenticação (tanto faz já que não há associação de segurança do IPsec aqui) |
Uma que estas políticas forem testadas e implantadas, as máquinas não pertencentes ao domínio não poderão se comunicar com aquelas que fazem parte do domínio. Porque? Os membros do domínio exigirão IPsec. Você não pode conseguir estas políticas a não ser que faça parte do domínio. Você não pode "fazer sua própria política" (roll your own) e tentar continuar de fora do domínio porque a política requer o Kerberos, que só funciona se você estiver no domínio. Todos os membros do domínio receberão a política e portanto poderão se comunicar com todos os outros membros do domínio. Lembre-se que se você permitir que usuários acrescentem e removam suas próprias maquinas do domínio, você não conseguirá controlar quem recebe e quem não recebe a política. Note que isto não é necessariamente um problema desde que fazer parte do domínio envolva a aplicação de outros controles de segurança como o SMS, antivírus, anti-spyware, um firewall, etc.
Espero que esta série de duas partes tenha o empolgado sobre algumas das coisas que você pode fazer com esta tecnologia incrível. Nós estamos esperando seus comentários - favor usar o link no final deste artigo. Obrigado pela leitura, e tenha uma ótima experiência com o uso do IPsec.
Políticas de Restrição de Software
| • | |
| • | |
| • | http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx |
Ferramentas de linha de comando do IPsec
| • | Windows 2000 Resource Kit: http://www.microsoft.com/windows2000/techinfo/reskit/default.asp |
| • | Windows XP Service Pack 2 Support Tools: http://support.microsoft.com/?kbid=838079 |
Isolamento do Domínio na Microsoft
| • | http://www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx |