MVP: System Center Cloud and Datacenter Management, MCT, MCSE, MCITP, MCPD, MCDBA
MVP Logo

Pageviews 2018: 3665002
Pageviews 2017: 4351543
Pageviews 2016: 3991973
Pageviews 2015: 2675433
Pageviews 2014: 2664208
Pageviews 2013: 2399409
Pageviews 2012: 3209633
Pageviews 2011: 2730038
Pageviews 2010: 1470924
Pageviews 2009: 64608

Últimos posts

Categorias

Arquivo

Tags

Microsoft ATA–Recuperação e Migração

Já falamos anteriormente sobre o Microsoft ATA (Advanced Threat Analytics) em http://www.marcelosincic.com.br/post/Microsoft-Advanced-Thread-Analytics-(ATA).aspx

Agora houve uma grande atualização com a versão 9 que tornou o ATA mais leve em demanda de recursos e visualização dos reports.

Porem, durante a migração é possivel que ocorram perdas de conexão ao MongoDB e ser necessário fazer o backup e restore.

O mesmo processo talvez seja necessário quando se troca de servidor ATA.

Importante: Os dados do Security Log do Windows é enviado ao Machine Learning para gerar os incidentes e alertas, mas ficam hospedados localmente. Portanto se perder o servidor não terá mais os reports e incidentes já registrados.

Realizando o Backup do ATA

Para fazer o backup da configuração do ATA é utilizado a cópia do arquivo SystemProfile_yyyymmddhhmm.json que fica na pasta de instalação do ATA em um subdiretório Backup junto com as ultimas 300 cópias dos dados.

Esse arquivo SystemProfile é a base de dados do MongoDB em formato JSON, eliminando a necessidade de fazer backup a partir do Atlas ou outra ferramenta especifica para administração do MongoDB. Isso é muito bom, pois não é comum conhecermos adminsitração do MongoDB.

Para funcionar deve-se ter a cópia do certificado usado para criptografia do arquivo JSON, que é gerado durante a instalação (Self-signed).

A cópia do certificado só precisa ser feita uma vez, abra o console do MMC com o snap-in Certificados e encontre o certificado de nome Central do ATA na área de certificados Pessoas em Local Machine.

Com estes passos temos o backup das configurações do servidor que são o JSON e o certificado. Mas e os dados do ATA?

Para fazer backup do ATA é necessário como já falado conhecer as ferramentas do MongoDB e talvez você deva pensar se precisará deles uma vez já resolvidos.

Se a sua necessidade é manter os alertas e incidentes, siga a documento em https://docs.mongodb.com/manual/core/backups/ de como fazer backups da base.

Realizando o Restore do ATA

A parte de restore do ATA em um novo servidor ou configuração de uma nova versão é um pouco mais complicado que o backup que é bem simples.

Primeiro é necessário importar o certificado exportado no passo anterior na mesma árvore da qual fez no passo anterior.

Em seguida é necessário reinstalar normalmente o novo servidor ATA com o mesmo nome e IP anterior e no momento que ele pedir o certificado desativar a opção Create Self-signed” para escolher o certificado original.

Em sequencia precisamos parar o serviço Centro ATA para podermos abrir o MongoDB e importar o arquivo JSON com os seguintes comandos:

  • mongo.exe ATA
  • db.SystemProfile.remove({})
  • mongoimport.exe --db ATA --collection SystemProfile --file "<Arquivo JSON> --upsert

Observação: Primeiro comando abre a instancia, o segundo remove as configurações vazias e o terceiro importa a nova configuração.

Não é necessário recriar os Gateways pois eles são mapeados automaticamente quando se restaura as configurações.

Caso você tenha feito backup da base de dados do MongoDB siga o procedimento de restore da base antes de reiniciar o serviço do ATA.

Referencia: https://docs.microsoft.com/pt-br/advanced-threat-analytics/disaster-recovery

Posted: out 24 2018, 15:02 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Windows Defender ATP–Entenda o Novo Produto

Parte dos novos recursos do Windows 10 é a capacidade de detalhamento na segurança e integração com recursos do Microsoft DCU (Digital Crime Unit), que é a unidade da Microsoft que trabalha com o departamento de defesa para gerar e identificar ataques ao redor do mundo (https://blogs.windows.com/windowsexperience/2016/03/01/announcing-windows-defender-advanced-threat-protection/).

Tipos de Proteção Disponiveis

Em geral os antivírus são baseados em DAT que são arquivos com assinaturas de vírus e conseguem identificar programas que tenham atividades ou parte destes códigos considerados perigosos. Nessa categoria estão todos os antivírus atuais, o que inclui o Windows Defender.

Já os sistemas de proteção avançados contem com análise comportamental interna e externa, ou seja, eles identificam potenciais ameaças por comportamentos como fazem alguns produtos da Symantec e McAfee, que identifica maquinas enviando pacotes para outras maquinas, logins com força bruta, etc.

Já os sistemas de proteção comportamental com análise externa são produtos bem diferentes. Eles analisam comportamentos de maquinas no ambiente e comunicações externas. Com isso é possível identificar:

  • Um grupo de maquinas recebendo pacotes de uma determinada maquina com conteúdo suspeito
  • Pacotes oriundos de países onde o ataque de phishing e similares são comuns
  • Pacotes oriundos de maquinas já identificadas como “zumbi”

Ou seja, com base na análise do próprio ambiente e de comportamento de hackers, é possível identificar que determinado hacker está tentando invadir uma empresa ao analisas que este hacker está enviando pacotes para a rede da empresa alvo.

 

O que é o ATA e o ATP

Nos produtos Microsoft esse produto é o ATA (Advanced Thread Analisys) que trabalha no Active Directory e logins, e o ATP (Advanced Thread Protection) que trabalha com Machine Learning (análise de dados) sobre os logs das maquinas individuais.

Na prática o Windows Defender ATP trabalha com o mesmo log que o Windows Defender, mas online e com base nas análises e dados do DCU. Com isso é possível identificar ameaças que não são encontradas nos tradicionais DAT ou com base apenas em uma única maquina que é a forma como os antivírus tradicionais trabalham.

O ATA é parte do EMS (Enterprise Mobility Suite), mas pode ser adquirido a parte: https://www.microsoft.com/pt-br/server-cloud/products/advanced-threat-analytics/overview.aspx

O ATP ainda está em preview com acesso por solicitação: https://www.microsoft.com/en-us/WindowsForBusiness/windows-atp

 

Overview do ATP

Como já possuo acesso ao ATP, vamos ver como ele funciona. Para pedir esse acesso, entre na página acima e complete com seus dados. É possível incluir maquinas de seu ambiente, mas o sistema gera algumas maquinas com vírus e problemas para testes automaticamente. Note nas telas abaixo que o usuário utilizado é gerado pela Microsoft para os testes.

Ao receber o acesso, o primeiro passo é indicar tempo de retenção e perfil da empresa que serve para elaborar threads por tipo de segmento:

capture20160724155740716

Na sequencia geramos o pacote ou o script para distribuição das configurações. Note que é possível criar os pacotes para distribuição por GPO, SCCM, Intune ou Local que é o que utilizarei nos meus testes:

capture20160724155906768

O passo seguinte é baixar o pacote, no meu caso o Local Script:

capture20160724155940968

O script contem um arquivo CMD para ser executado manualmente nas maquinas que desejo que o log do Defender seja enviado para o ATP. Esse script cria uma chave no registro para indicar o meu tenant e ativar o ATP:

Capturar

A partir de agora as suas maquinas passarão a enviar dados para o ATP em algumas horas.

No caso do meu teste, posso utilizar os dados da maquina que a Microsoft gera com testes e ver os alertas e o dashboard. A primeira tela é o Dashboard que indica o comportamento geral no ambiente monitorado:

capture20160724161031396

Neste caso não tenho alertas gerados nos últimos 30 dias, mas tenho os de criação do tenant para demonstrar como utilizar o gerenciamento de alertas:

capture20160724155810843

Cada alerta pode ser ignorado, marcado como resolvido ou suprimido em todo o tenant ou apenas para esta maquina específica:

capture20160724155833547

 

Conclusão

Este tipo de análise dos dados é essencial para a segurança da corporação. Em breve disponível como serviço no Azure, o ATP é uma nova forma de analisar e garantir seu ambiente.

Novo Azure AD Connect

Na semana passada a Microsoft liberou a nova ferramenta para sincronização de AD local com o Azure AD. Essa nova ferramenta tem as mesmas funcionalidades das anteriores DirSync e ADDSync, mas acrescesta facilidade na administração do serviço e acesso aos conectores.

Para baixar e ver detalhes: https://azure.microsoft.com/en-gb/documentation/articles/active-directory-aadconnect/

1-Resumo

Instalação e Upgrade do Dirsync

Para quem já tem o Dirsync ou o ADDSync instalado o Azure AD Connect irá fazer o upgrade e solicitar apenas a credencial do Azure para configurar, mas após o upgrade é possivel alterar facilmente as configurações.

A sequencia abaixo mostra o upgrade, sendo bem simples pedindo apenas as contas online e on-premisse:

2-Upgrade Dirsync

3-Conect

 4-Conect2

 5-Upgrade

Configuração Pós-Instalação

A interface do Azure AD Connect é realizada com ferramentas gráficas acessiveis pelo Menu Iniciar:

6-Iniciar

A ferramenta que torna mais fácil configurar como comentado no inicio do artigo é o Synchronization Service, onde ao abrir já é possivel ver os conectores habilitados, o estado da sincronização, log das ultimas sincronizações e utilitários na lateral:

7-Sinc Service

Por exemplo, para sincronizar manualmente basta clicar sobre uma das conexões e escolher como quer sincronizar (Connectors –> Run):

8-Sincronizarmanual

Visualização, Atualização e Criação de Conectores

Ao clicar em qualquer um dos conectores abre-se um wizard onde podemos alterar os conectores básicos ou criar novos conectores.

O wizard é muito simples e funcional, como mostram as imagens abaixo utilizando o Properties:

9-Conectores1

10-Conectores2

E para criar novos conectores, ao clicar em Create temos criar os diversos tipos de conectores on-premisse ou online utilizando o wizard das imagens acima.

11-Conectores3

Vale a pena fazer o upgrade para quem tem o Dirsync e o AADSync, pois esta nova ferramenta é muito completa e simples facilitando o acesso aos configurações, alterações e log das operações.

Posted: jun 29 2015, 12:18 by msincic | Comentários (0) RSS comment feed |
  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Alteração no Kerberos do Windows 2012 pode causar Acesso Negado

Em uma reunião com os Microsoft PFEs Gilson Banin e Marcelo Ferratti foi comentado sobre uma alteração no método como o Windows 2012 gera um Ticket de autenticação pelo Kerberos, chamado de “KDC Resource SID Compression”.

Situação Atual

Como já é sabido, um Ticket de autenticação leva o SID do usuário e dos grupos do qual ele faz parte, além do SID History em casos de migração anterior. Em alguns casos, principalmente dominios muito grandes, o Ticket podia estourar o limite padrão de 12 Kb e gerar problemas na autenticação. Vale lembrar que pelo mesmo motivo um usuário não pode fazer parte de mais do que 1024 grupos.

Atuamente o Ticket (PAC) é composto por SIDs completos: Os valores padrão de identificação (S-1-5), o SID do dominio e o RID individual do objeto no ultimo bloco:

  • S-1-5-21-3419695430-3854377854-1234
  • S-1-5-21-3419695430-3854377854-1466
  • S-1-5-21-3419695430-3854377854-1675
  • S-1-5-21-4533280865-6432248977-6523
  • S-1-5-21-4533280865-6432248977-6578

Alteração no Windows 2012

A mudança no KDC consiste em não mais incluir no Ticket dados repetidos, com isso o Ticket gerado por um Domain Controller com Windows 2012 fica com menor tamanho e resolve o problema de ser necessário a alteração do tamanho do Ticket.

Assim, o mesmo exemplo anterior de Ticket ficaria:

  • S-1-5-21-3419695430-3854377854-1234
  • -1466
  • -1675
  • S-1-5-21-4533280865-6432248977-6523
  • -6578

O problema é que servidores anteriores ao Windows 2012 não “entendem” o novo Ticket e só permitirá acesso as ACEs que sejam completas, portanto o usuário conseguiria acessar locais onde a permissão foi concedida nos casos 1 e 4 do exemplo, mas não acessaria caso a permissão seja de um dos outros SIDs.

Conclusão

Em um dominio onde ainda existam servidores anteriores ao Windows 2012, o que inclui o Windows 2008 R2, o acesso ao servidor de arquivos, Exchange e qualquer outro que seja baseado no Kerberos terá problemas de acesso negado.

Remediação

Crie a chave de Registry Dword DisableResourceGroupsFields  em HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kdc\Parameters para desabilitar este recurso.

 

Mais Informações: http://support.microsoft.com/kb/2774190

Posted: out 28 2012, 23:20 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Artigos no Wiki MIVP #12–System Center Orchestrator Automatizando Tarefas

Continuando a parceria com a agência de publicidade para a montagem de 20 artigos referentes a Private Cloud com System Center 2012, esta semana publicamos o artigo no portal MIVP do Wiki, desta vez focados no System Center Orchestrator http://social.technet.microsoft.com/wiki/contents/articles/12298.system-center-orchestrator-automatizando-tarefas-pt-br.aspx

O artigo aborda a instalação, configuração, importação de Integration Packs, criação de Runbooks, gerenciamento no console web e uma demo em video.

Em breve os próximos artigos que irão abordar App Controller e SCVMM:

  • System Center AppController - Monitore Aplicações
  • System Center Virtual Machine Manager 2012 - Instalação, Configuração e Administração
  • System Center Virtual Machine Manager 2012 - Administrando Multiplos Hypervisors
  • System Center Virtual Machine Manager 2012 - Serviços, Automação de Storage e Network

Series:

Posted: jul 12 2012, 15:42 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Login