sexta-feira, 5 de fevereiro de 2010

Criando Subscription para Encaminhamento de Logs com Windows Server 2008

A centralização de logs nativamente no Windows sempre foi um recurso bastante esperado pelos administradores de sistemas, principalmente pelo fato de que nas versões anteriores não era possível centralizar as informações dos Logs de Eventos, já na versão 2008 do Windows Server isto é plenamento possível com a criação de Subscriptions.
 
Neste tutorial, iremos criar um subscription para coletar logs de um servidor Windows Server Core 2008 R2. A idéia é facilitar a tarefa do adminsitrador que lida com a nova ferramenta da Microsoft que não conta com uma interface gráfica permitindo a centralização dos logs sem a necessidade de acessar o Event Viewer remotamente.
 
Cenário do Tutorial:
Figura 1 – MARDUK com Windows Server 2008 onde iremos configurar o Subscription para coletar logs e TRINITY com Windows Server 2003 que irá gerar logs.
 
1. Primeiro Passo – Atribuindo Permissão Para Comunicação
É preciso que a máquina que irá coletar os logs (MARDUK no nosso exemplo) seja membro do grupo local Administrators. Para isto, acesse a máquina que irá gerar os logs (TIAMAT no nosso exemplo) e insira a conta de computar do servidor que centraliza os logs (MARDUK no nosso exemplo).

Figura 1 – Inserindo conta de computador no grupo Administrators do Server Core
Obs.: O Server Core não tem interface gráfica, para habilitar o acesso remoto através de console MMC, confira o seguinte artigo:

2. Segundo Passo – Habilitando Protocolo Remoto
Será preciso configurar o Windows Remote Management para permitir que os logs sejam coletados pelo servidor que irá concentrar as informações, para isto acesse o prompt do Server Core e digite:

winrm quickconfig


Figura 2.1 – No prompt do Server Core, execute a linha de comando winrm quickconfig
e ao ser questionado pressione Y. Perceba que com este comando além de habilitar o serviço para aceitar requisições, o firewall também é automaticamente configurado para habilita a exceção.
   
3. Terceiro Passo – Configurando Subscription
Agora devemos criar um Subscription com as definições de log e informações do computador o qual os logs serão coletados. Nesta etapa é bem importante ficar atento aos testes de conectividade e tipo de informação que quer obter da máquina, então tenha em mãos o escopo para configurá-lo.
 
3.1 Abra o console do Event Viewer, expanda Windows Logs e clique com o botão direito sobre Subscriptions. Então escolha a opção Create Subscription...

Figura 3.1 – Criando Subscrition
 
3.2 Dentro das propriedades deveremos preencher todas as informações necessárias, começando pelo nome da subscription, e neste caso o detalhe importante é selecionarmos qual o destino do log, ou seja, onde os logs aparecerão no servidor central.

Figura 3.2 – Nomeando o Subscription e definindo o destino dos logs
 
3.3 Precisamos agora definir o computador que irá ser contactado para a coleta dos logs, este computador é chamado de fonte (TIAMAT no nosso exemplo) e receberá a visita do servidor central (MARDUK no nosso exemplo) para entregar os logs correspondentes.

3.3.1 Clique sobre o botão Select Computers...
3.3.2 Na caixa de diálogo Computer clique sobre o botão Add Domain Computers...
3.3.3 Após selecionar o computador desejado, clique no botão Test para verificar a conectividade


Figura 3.3 – Definindo Computador Fonte que irá "publicar" os logs para o servidor central coletar
 
3.4 Após inserir o computador fonte, vamos configurar os filtros de log, ou seja aqui definiremos os tipos de eventos que queremos monitorar a partir do servidor central.
 
    3.4.1 Ainda em propriedades de Subscriptions, clique no botão Select Events...
    3.4.2 Na tela Query Filter selecione os Event Level, neste exemplo selecionamos os mais comuns.
    3.4.3 Selecion o evento que quer monitor, neste exemplo selecionamos System.

Figura 3.4 – Definindo nível e tipo de logs que serão coletados
 
3.5 Agora deveremos garantir que as configurações avançadas estejam corretas para completar o processo de coleta dos logs, para isto clique no botão Advanced em propriedades de Subscription confira os seguntes pontos:


  • User Account: Utilize Machine Account conforme a configuração que declaramos no primeiro passo, porém em alguns casos poderemos utiliza a conta do Administrador para isto.



  • Event Delivery Optimization: O nível Normal garante atualização de 15 em 15 segundos, caso você tenha uma largura de banda restritiva poderá optar por Minimize Bandwith para aumentar o tempo de atualização para 40 em 40 segundos.



  • Protocol: Estamos utilizando HTTP para efeito de demonstração, mas você poderá alterar para HTTPS provendo criptografia no trafego das informações, isto é desejável .



  • Port: Tenha certeza de que a porta de tráfego do Windows Remote Management está ativada nestas configurações e habilitada na estrutura de firewall.

Figura 3.5 – Configurações Avançadas da Subscription
 
3.6 Com a Subscription configurada, agora precisaremos validar se a comunicação está efetivamente funcional, apesar de testarmos a comunição do Windows Remote Management no item 3.3.3, precisamos validar a autenticação e o tráfego no protocolo e porta. Clique com o botão direito sobre a Subscription recem criada e escolha a opção Runtime Status, ao abrir o status do Subscription verifique se aparece Active e clique em OK.


Figura 3.6 – Validando Status da Subscription
 
4. Quarto Passo – Gerando Log No Servidor Server Core
Para que apareçam os esperados logs, é preciso gerar um de teste. Temos várias opções, dentre elas reiniciar o computador, mas vamos a uma prática menos nociva. Iremos parar o serviço Secondary Logon, com o seguinte comando (lembre-se que é Server Core):
  
net stop seclogon

Figura 4 – Parando serviço Secondary Logon para criar logs

5. Quinto Passo – Analisando Logs Em Forwarded Events no Windows Server 2008
Pronto, agora que geramos o erro podemos acompanhar os logs que deverão aparecer no nosso servidor central coletor de logs, mas intimamente conhecido como MARDUK, no nosso exemplo é claro. Para isto iremos acessar o diretório de destino em Event Viewer chamado Forwarded Events, vale lembrar que selecionamos a otimização normal e por isto deveremos esperar no mínimo 15 segundos para que os logs efetivamente apareçam.
Vejam na imagem abaixo que temos vários logs e dentre todos, temos nosso log de informação mostrando que o serviço Secondary Logon foi parado no computador TIAMAT.

Figura 5 – Em Forwarded Events no servidor central (MARDUK) aparecem os logs do computador fonte (TIAMAT)
 
Neste tutorial, vimos como centralizar logs de servidores na plataforma Microsoft Windows Server Core 2008, a partir da nova função Subscription no Windows Server 2008.


Abração a todos!

Habilitar Acesso Remoto ao Firewall em Servidor Server Core 2008

Olá Pessoal,

Uma das tarefas mais arduas na minha opinião é administrar o advfirewall (advanced firewall) na plataforma server core, por isto sempre que faço uma implementação nesta plataforma imediatamente habilito o remote management, assim posso remotamente configurar o advfirewall através de um mmc (Microsoft Management Console) em outro servidor ou até mesmo da minha estação de trabalho.
Ao tentar customizar um mmc para administrar o advfirewall do server core, você poderá deparar-se com a seguinte situação:

Isto acontece porque por padrão o advfirewall bloqueia o gerenciamento remoto, então você deverá no servidor server core utilizar a ferramenta de linha de comando netsh para habilitar o remote management (Irônico, não!? rsrs... Mas é isto mesmo.), segue o comando:

netsh advfirewall set currentprofile settings remotemanagement enable

Pronto! Feito isto você receberá um OK, conforme a imagem abaixo:


Retorne no seu mmc customizado com o advfirewall do server core e atualize o snap-in:

 

Agora você tem autonomia total através de uma ferramenta intuitiva para administrar o advfirewall do sua plataforma em server core. Concordam que é muito melhor do que sair desabilitando o firewall para rodar algumas ferramentas, não é?

Ah! para desabilitar o remote management é só mudar o final do comando de enable para disable:

netsh advfirewall set currentprofile settings remotemanagement disable

Bem, fico por aqui... Forte abraço a todos!!

quarta-feira, 27 de janeiro de 2010

Calcular Subnets e Entendendo os Saltos

Vamos falar de subnets? É extremamente impostante que um IT Professional tenha a capacidade de calcular subnets, por conta disto iremos juntos trabalhar com um ambiente e entender como fazer para cumprir com esta tarefa sem sofrer, rs...

Imaginem que solicitado a você criar uma 08 subnets, mas sua responsabilidade é permitir uma expansão futura para mais quatro subnets adicionais e a rede da sua empresa é de classe B 172.23.0.0. Muito bem, nossa responsabilidade aqui é equalizar a necessidade atual e suportar a demanda futura, então começaremos definindo o número de divisões possíveis para chegar no total de subnets exigida.
Como precisaremos pensar em 12 subnets iremos aplicar a regra de 2N (dois elevado a N que é igual a notação decimal que compoe o total de divisões possíveis). Vamos lá...

2*4 = 16

Isto quer dizer que iremos utilizar 4 bits para a nossa operação, isto em uma composição binária seria:

11111111.11111111.11110000.00000000
255.255.240.0 = 172.23.0.0/20


Ótimo, chegamos na mascara de rede! Já sabemos que dentro desta notação poderemos incluir 16 subnets, agora precisaremos descobrir quais os saltos que ocorrerão na composição das subnets, certo? Isto é simples basta olharmos para o bit de baixa ordem, no nosso caso o 16 (Como assim 16 Marcelão!?!?! Lembra da notação decimal? Cada bit do octeto tem um valor da direita para a esquerda elevando 2 de 0 até 7, faça as contas e verás que quando chegar no bit número 5 teremos que elevar a 4. Logo 2 elevado a 4 é igual a 16). Então os saltos irão ocorrer de 16 em 16 ficando assim:

Rede Original: 172.23.0.0
Mascara Original: 255.255.0.0

Subnet 1: 172.23.0.0
10101100.00010111.00000000.00000000

Subnet 2: 172.23.16.0
10101100.00010111.00010000.00000000

Subnet 3: 172.23.32.0
10101100.00010111.00100000.00000000

Subnet 4: 172.23.48.0
10101100.00010111.00110000.00000000

Subnet 5: 172.23.64.0
10101100.00010111.01000000.00000000

Subnet 6: 172.23.80.0
10101100.00010111.01010000.00000000

Subnet 7: 172.23.96.0
10101100.00010111.01100000.00000000

Subnet 8: 172.23.112.0
10101100.00010111.01110000.00000000

Subnet 9: 172.23.128.0
10101100.00010111.10000000.00000000

Subnet 10: 172.23.144.0
10101100.00010111.10010000.00000000

Subnet 11: 172.23.160.0
10101100.00010111.10100000.00000000

Subnet 12: 172.23.176.0
10101100.00010111.10110000.00000000

Subnet 13: 172.23.192.0
10101100.00010111.11000000.00000000

Subnet 14: 172.23.208.0
10101100.00010111.11010000.00000000

Subnet 15: 172.23.224.0
10101100.00010111.11100000.00000000

Subnet 16: 172.23.240.0
10101100.00010111.11110000.00000000

Nova Mascara: 255.255.240.0
11111111.11111111.11110000.00000000

Primeiro Host: 172.23.0.1
Ultimo Host: 172.23.240.254
Broadcast: 172.23.240.255

Ufa! É isto ai... Neste post aprendemos a calcular subnets e entendemos como são calculados os saltos entre elas.

Abração!

Treinamento ISA Server 2006

Olá a todos,

Aqueles que estão ou querem estar na área de segurança e procuram um treinamento focado no ISA Server, eu recomendo fortemente o Training Day do ISA Server 2006 com o Bruno César Silva. O Brunão é MVP Enterprise Security que tem grande experiência com o produto (é lógico até pela premiação do cabloco, rs) e para melhorar o cara é fera como instrutor. Trabalhamos juntos em turmas grande de treinamento MCSA e sei o que estou dizendo...
Bom, para os interessados segue o link do blog dele, confiram as datas:
http://brunocesarsilva.spaces.live.com/blog/cns!13E484954FB5A846!604.entry


Caso queiram ir direto ao site MCP Brasil e efetuar a reserva, acessem:

É isto ai pessoal, não percam esta oportunidade...

Forte abraço,

terça-feira, 26 de janeiro de 2010

Network Virtual Service Provider Bind

Anunciado no dia 25 de Janeiro de 2010 no blog de John Howard, uma nova ferramenta que irá ajudar aqueles que utilizam a versao Server Core para virtualizar ou o Hyper-V Server. a funçao do NVSPBind (Network Virtual Service Provider Bind) é ajudar-nos no processo de habilitar ou desabilitar protocolos de rede. Sim! Esta simples tarefa que é possivel ser feita simplesmente clicando em um checkbox, era até entao um grande problema para os usuários da versao Server Core. O aplicativo foi desenvolvido por Keith Mange que faz parte do time de Hyper-V da Microsoft.
Para maiores informaçoes e download:
http://code.msdn.microsoft.com/nvspbind

Abraço,