Migração do Servidor de Arquivos com as Ferramentas de Migração do Windows Server - Além do Robocopy

Para quem trabalha com infra-estrutura sabe o quanto é trabalhoso e “perigoso” migrar o servidor de arquivos, pois a migração deve envolver a transferência dos dados, bem como o controle de acesso (permissões), ou seja, quem tinha acesso antes da migração deve continuar a ter acesso, e quem não tinha acesso deve continuar a não ter.

Para ajudar nesse processo a Microsoft incluiu no Windows Server 2012 um módulo do Windows PowerShell que contém 5 cmdlets, esses cmdlets são chamados de Ferramentas de Migração do Windows Server. Existem dois cmdlets (Send-SmigServerData e Receive-SmigServerData) que trabalhando em conjunto permitem migrar “ao vivo” os compartilhamentos de arquivos e suas permissões para outro servidor.

No exemplo desse artigo o servidor origem é o Windows Server 2003 SP2 e o servidor de destino é o Windows Server 2012. Vou assumir que as Ferramentas de Migração já estejam instaladas em ambos os servidores.

Obs.: A instalação das ferramentas de migração são abordadas no meu artigo: Instalação das Ferramentas de Migração do Windows Server.

Vamos migrar o compartihamento Home Users, esse compartilhamento contém uma sub-pasta privativa para cada usuário. Veja a estrutura na imagem abaixo.

Observe a guia Segurança da pasta User1. Veja que somente os Administradores do domínio, o sistema, e o próprio usuário possuem acesso a pasta.

Supondo que as Ferramentas de Migração do Window Server já estejam instaladas no servidor de origem e no servidor de destino, siga os procedimentos a seguir:

1. No servidor de origem clique em: Iniciar >Ferramentas de Administrativas >Ferramentas de Migração do Windows Server >Windows Server Migration Tools.

2. A  transferência dos dados é criptografada por uma senha, por isso vamos criar um objeto de senha do Windows PowerShell:

$pwd = (Read-Host “Digite a Senha” –AsSecureString)

3. Agora vamos enviar os dados, as configurações de compartilhamento, e as permissões NTFS para o computador SRV-2012.

Send-SmigServerData -include All -Computername SRV-2012 -SourcePath "C:\Home Users" -DestinationPath "H:\Home Users" -Recurse -Password $pwd -V

4. No servidor de destino Abra as Ferramentas de Migração do Windows Server

5. Crie um objeto de senha do Windows PowerShell com a mesma senha utilizada na etapa de envio. (Informe a mesma senha utilizada no envio dos dados.)

$pwd = (Read-Host “Digite a Senha” –AsSecureString)

Receive-SmigServerData –Password $pwd

Após o termino do processo de migração, verifique no servidor de destino as pastas, os dados, e as configurações de compartilhamento e NTFS.

6. Após a confirmação de que a migração ocorreu com sucesso, desconecte o servidor antigo da rede e refaça os mapeamentos de rede para apontarem para o novo servidor.

Obs.: Não copie e cole os comandos. Ao invés disso digite-os (a formatação pode invalidar o comando)

Que tal vocês testarem os seus conhecimentos hacker?

O pessoal que mantêm o www.100security.com.br/ acaba de lançar um wargame, uma ambiente controlado, vulnerável liberado para galera testar os seus conhecimentos hacker.

Mais detalhes poderão ser obtidos na seguinte URL www.100security.com.br/wargame

Pensar fora da caixa é fundamental, as vezes o que você acha improvável pode revelar segredos valiosos.

Windows – Onde o Usuário Logou ou está Logado?

Saber em qual Computador ou Servidor um determinado Usuário Logou ou está Logado pode ser necessário em um processo de Auditoria, e como já é de conhecimento de todos temos inúmeras formas de fazer isso, há muitas ferramentas que podem auxiliar neste levantamento.

Meu objetivo com este artigo é mostrar algumas das formas mais básicas e funcionais de se fazer isso em um ambiente de rede.

// Espero que possa ajudar alguém, deixe seus comentários sobre as formas ou soluções que você utiliza para ajudar outras pessoas.

Cenário:

Para facilitar o entendimento montei o cenário abaixo onde o objetivo é localizar onde os usuário 100SECURITY\marcos logou ou esta logado.

OPÇÃO 01 – PsLoggedon

Utilizando a ferramenta PsLoggedon.exe da SysInternals você pode saber quais usuários estão logados em um determinado host.

Download: technet.microsoft.com/en-us/sysinternals/psloggedon.aspx

01 Passo

Após descompactar o arquivo PSTools.zip entre no diretório PsTools e execute o comando:

C:\>cd PsTools

C:\PsTools>PsLoggedon.exe -x \\SRV-2008

Resultado:

Os usuários abaixo estão logados no Servidor SRV-2008:

SRV-2008\Administrator
100SECURITY\marcos

OPÇÃO 02 – qwinsta e rwinsta

Você pode utilizar o comando responsável por exibir as informações sobre as sessões dos Serviços de Área de Trabalho Remota: qwinsta

01 Passo

Execute o comando qwinsta seguido do parâmetro /SERVER:<HOST>

C:\>qwinsta /SERVER:SRV-2008

Resultado:

São exibidas as sessões remotas que estão ativas no servidor SRV-2008

02 Passo

Caso você queira finalizar uma das sessões ativas basta utilizar o ID da sessão.

Execute o comando rwinsta

C:\>rwinsta 1 /SERVER:SRV-2008

ID 1 – Corresponde ao usuário Administrator

Em seguida execute o comando qwinsta novamente para certificar que a sessão foi finalizada.

Confirmando no Servidor: SRV-2008

OPÇÃO 03 – Active Directory | EventViewer | PowerShell

Quando um usuário loga no domínio o acesso é registrado no evento 4624 do Log Security e através deste evento é possível identificar em qual o ip do computador que o usuário esta ou estava utilizando no momento deste logon.

01 Passo

Dentro do servidor de Active Directory no exemplo DC-2012 acesse o Event Viewer > Windows Logs > Security e clique na coluna EventIDpara filtrar todos os eventos, em seguida localize o evento 4624

02 Passo

Escolha uma data e de um duplo-clique no evento 4624 para visualizar todo seu conteúdo.

Observe as linhas:

Account Name: marcos – Exibe o usuário que se logon no domínio.

Source Network Address: 192.168.1.201 – Informa em qual host o usuário marcos se logon, este IP refere-se ao servidor SRV-2008.

03 Passo

Utilizando o Power Shell você pode extrair todos os logons realizados pelo usuário marcos, basta executar o script abaixo:

// Crie a pasta auditoria para centralizar os relatórios.

PS C:\>cd .\auditoria
PS C:\auditoria>Get-EventLog -LogName Security -InstanceID 4624 | Where {$_.Message -match “Account Name:\s+marcos“}

Resultado:

Mostra que o usuário marcos se logou no domínio através do host 192.168.1.201

OPÇÃO 04 – Relatório de Conexões RDP em um Servidor

Este script em Power Shell vai ajudá-lo a identificar todos os LOGON/LOGOFF que foram realizados em um ou mais servidores incluindo o computador que foi utilizado para o acesso.

01 Passo

Realize o download do script: clique aqui em seguida execute-o.

PS C:\>.cd .\auditoria
PS C:\auditoria>.\relatorio_rdp.ps1

Resultado:

A data esta no formato americano mas você pode customizar o script como quiser.

Veja mais em: http://www.100security.com.br

MELHORES PRÁTICAS PARA PROTEGER O ACTIVE DIRECTORY

Conforme o tempo vai passando os domínios vão se modernizando, com novas estações, usuários e aplicativos inseridos. Mas com a atualização dos domínios, outras partes da infraestrutura vão sendo esquecidas e acabam dando brechas para ataques. Os invasores aproveitam destas lacunas para se inserirem no domínio e conseguirem senhas e privilégios de usuários importantes no seu Active Directory através de keylogger instalados na estação.

E é por causa da demanda cada vez maior, que temos que ter noção de como os invasores atacam o AD e saber quais são as melhores práticas recomendadas pela Microsoft.

Algumas das partes da infraestrutura que acabam sendo “esquecidas” com o passar do tempo e acabam dando brechas para ataques, são:

• S.O e aplicativos obsoletos: sistemas em que os fornecedores não dão mais suporte aos mesmos, acabando não surgindo novos upgrades para corrigir falhas;

• Antivírus: não fazer a atualização dos antivírus nas estações e nos servidores, dando mais vulnerabilidade ao seu ambiente;

• Dispositivos de funcionários pessoais ligados em rede: o uso compromete o seu domínio, uma vez que não sabemos quais programas estão instalados nestes dispositivos;

• Utilização de ambientes mistos: é o uso de sistemas Microsoft e não Microsoft em seu ambiente, uma vez que acabam dando mais atenção à um e esquecendo do outro.

Algumas das práticas recomendadas para proteger seu AD são:

• Monitorar Logs referentes ao Active Directory;

• Fazer a desativação do usuário administrador local nas estações. (Caso precise utilizar o administrador local, podemos habilitá-lo no modo de segurança por uma GPO em que ative o mesmo temporariamente ou utilizar grupos restritos para este fim);

• Não acessar estações não confiáveis com usuários que sejam administradores de empresa, domínio, etc;

• Usar o mínimo privilégio possível aos usuários do AD (Ou seja, o usuário só deve ter permissão ao que ele irá fazer. Não dando nenhuma permissão a mais);

• Reduzir os usuários dos Grupos Administradores do domínio, empresa, etc do seu AD;

• Fazer a delegação de poderes administrativos. (Delegar poderes em relação a tarefa específica. Por exemplo: usuários que trabalham necessitando instalar impressoras em rede, atribua ao grupo Operadores de impressão e não um grupo mais elevado);

• Atribuir auditorias importantes (Logon, alterações no AD, pastas..).

Apesar destas falhas não estarem diretamente ligadas ao Active Directory, elas são porta de entrada para o comprometimento do mesmo, uma vez que o invasor se aproveita dessas falhas para se proliferar na estação e depois obter senhas de usuários importantes no AD, tais como: Administradores do domínio, Administradores de empresa e Administradores de esquema.

Usuários estes em que podem comprometer todo seu domínio com alterações inadequadas. Outros usuários bastante vistos pelo invasores são os usuários VIPs. Estes usuários são aqueles que tem acessos importantes como a documentação da empresa e a dados sigilosos que podem consequentemente levar a senha dos usuários administradores do Active Directory.

Há outras importantes recomendações para o seu AD que serão postadas mais para frente. Caso tenha algo a complementar, por favor, deixe seu comentário abaixo!

Este artigo também pode ser visto em: https://diegogouveiace.wordpress.com