Sobre DNS Policies–Windows Server 2016–volume 05–DNS Filtering

19 de junho de 2017 2 comentários

Saudações! Depois de atuações em alguns auditorias de cybersecurity estamos aí de novo pra continuidade dessa interessante série de posts falando sobre DNS Policies no Windows Server 2016.

A quem está chegando agora, abaixo os links para os outros 4 posts da série:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

Sobre DNS Policies – Windows Server 2016 – volume 04 – Split Brain DNS e Selective Recursion Control

Hoje, neste 5o. post desta série, vamos falar sobre DNS Filtering, que são filtros de critérios baseados em requisitos definidos na criação da política propriamente dita, ou seja, a resposta de um DNS Server ocorrerá de acordo com a maneira que um cliente faz a query.

Todos os termos associados aos procedimentos de criação de policies podem ser vistos nos posts anteriores desta série, pois, aqui vamos entrar de forma mais dinãmica no que podemos fazer em termos de Filtering via DNS Policies.

1. Bloqueando queries para um domínio:

Você pode impedir que seu DNS resolva requisições para um determinado domínio. Vamos supor que eu não queira que meus usuários acessem nada que seja do domínio *.malicious.org:

Add-DnsServerQueryResolutionPolicy -Name "BlockedDomains" -Action IGNORE -FQDN "EQ,*.malicious.org" –PassThru

No exemplo acima eu criei uma policy chamada “BlockedDomains” que vai ignorar tudo que for igual (EQ) a “malicious.org”.

2. Bloqueando queries para uma subnet:

Vamos agora supor que eu precise bloquear o acesso a uma subnet, ou seja, uma quantidade de endereços os quais eu teria mais trabalho em bloquear um a um:

Add-DnsServerClientSubnet -Name "BlockedSubnet" -IPv4Subnet 129.214.16.0/24 -PassThru

Add-DnsServerQueryResolutionPolicy -Name "BlockedSubnetPolicy" -Action IGNORE -ClientSubnet  "EQ,BlockedSubnet" -PassThru

No pirmeiro comando eu criei uma subnet chamada “BlockedSubNet” onde eu defino a subnet 129.214.16.0/24. No segundo comando eu crio uma regra chamada “BlockedSubnetPolicy” que ignora tudo o que estiver na range de IP citada.

Este filtro pode ser ainda mais incisivo. Vamos supor que eu queira bloquear acessos a tudo que estiver na subnet acima citada que responda pelo domínio *.malicious.org, ou seja, tudo que responder pelo domínio citado e estiver dentro da subnet criada será ignorado:

Add-DnsServerQueryResolutionPolicy -Name "BlockedSubnetPolicy" -Action IGNORE -ClientSubnet  "EQ,BlockedSubnet" –FQDN “EQ,*.malicious.org” -PassThru

3. Bloqueando e liberando tipo de queries

Vamos fazer um mini lab! Eu vou bloquear toda e qualquer consulta a partir do meu DNS Server e depois vou liberando de acordo com a necessidade.

Add-DnsServerQueryResolutionPolicy -Name "BlockAll" -Action IGNORE -QType "EQ,ANY" –PassThru

Cuidado: O comando acima simplesmente bloqueia todo tipo de queries e requisições a seu DNS. Então planeje bem ao usar o parâmtro ANY.

Agora vou fazer a liberação de determinados tipos de queries. O comando abaixo libera queries do tipo A, AAAA, MX, NS e SOA a partir da interface interface interna do meu DNS Server (10.10.1.20):

Add-DnsServerQueryResolutionPolicy -Name "WhiteListQType" -Action IGNORE -QType "NE,A,AAAA,MX,NS,SOA" –ServerInterface “EQ,10.10.1.20” -PassThru

Vamos agora a outros tipos liberação. Vamos liberar as consultas para meu domínio interno:

Add-DnsServerQueryResolutionPolicy -Name "Whitelist" -Action IGNORE -FQDN "NE,*.uilson.net" –PassThru

O comando acima cria uma white list liberando consultas a tudo que vier do domínio uilson.net, usando o parâmetro NE (Not Equal).

Agora vamos liberar o acesso a uma determinada subnet. Vamos repetir alguns parâmetros do comando exibido no item 2 deste post:

Add-DnsServerClientSubnet -Name "WhiteListSubNet" -IPv4Subnet 129.214.16.0/24 -PassThru

Add-DnsServerQueryResolutionPolicy -Name "WhitelistAllowedSubnetPolicy” -Action IGNORE -ClientSubnet  "NE, WhiteListSubNet" –PassThru

Nos comandos acima criei uma subnet chamada WhileListSubnet contendo a range 129.214.16.0/24 que será liberada para consultas DNS a partir da policy WhiteListAllowedSubNetPolicy.

4. Conclusão

Neste post mostrei exemplos de aplicação de filtros a partir do DNS Policies no Windows Server 2016. Como sempre digo aqui, espero que o conteúdo seja útil e possa ajuda-lo em seu dia a dia.

No próxima post da série irei mostrar DNS Policies para foresincs.

Abraços

Uilson

Sobre DNS Policies–Windows Server 2016–volume 04–Split-Brain DNS e Selective Recursion Control

29 de maio de 2017 Deixe um comentário

Saudações,

Peço desculpas pela demora na publicação do quarto volume desta série. Estive em dias de muito trabalho e alguns percalços pessoais. Mas de qualquer forma vamos ao conteúdo de hoje – Split-Brain DNS.

A quem está chegando agora, abaixo os links para os outros 3 posts da série:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

De acordo com a teoria que coloquei no volume 1 desta série, com o recurso de Split-Brain DNS os registros são divididos em diferentes escopos de zona no mesmo servidor DNS. Os clientes DNS recebem uma resposta baseado onde de fato estes clientes estão – internos ou externos. Este recurso pode ser configurado em zonas integradas ao AD ou para DNS Standalone Servers.

Também iremos criar políticas de seletive recursion para mitigação e vulnerabilidades em ambientes como este.

Em tempo – Este laboratório foi criado em meu ambiente tendo como base o laboratório do artigo Split-Brain DNS Deployment Using Windows DNS Server Policies do pessoal do Networking Blog da Microsoft. Como não tinha montado nada semelhante, me espelhei no conteúdo deles para criar o meu. Para aqueles que notarem a semelhança do meu lab com o deles, fica aqui registrado que a idéia inicial é do link citado e deixo a eles o devido crédito.

Vamos então a parte prática!

Imaginemos que tenho um site que deverá ser acessado tanto por usuários internos quanto externos. Esse possui informações de produtos da minha empresa que a equipe compartilha com parceiros externos.

Meu DNS posui duas interfaces, uma interna e outra externa

Interna – IP 10.10.1.100

Externa – IP 200.185.0.55

Meu servidor de aplicação interno responde pelo IP 10.10.1.10 e meu servidor de aplicação externo responde pelo IP 66.56.40.10 (lembrando que estes são IP´s fictícios, os IP´s que usei no laboratório do meu ambiente são outros e aqui fica só para ilustração)

Objetivo – Usuários na minha rede interna, irão acessar o site produtos.uilson.net do back-end Server interno e usuários externos irão acessar o back-end server externo, conforme o desenho abaixo:

 

image

Com o cenário definido, vamos ao procedimento que torna tudo isso real:

Vamos começar criando um zone scope para o acesso interno, ou seja, os acessos que virão pela interface 10.10.1.100:

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “InternalAccess”

Iremos criar o zone scope somente para o acesso interno, ficando o acesso externo direto no zone uilson.net no escopo padrão.

Agora vamos criar criar os registros para os acessos interno e externo, sendo que, para o acesso interno, iremos cria-lo já dentro do zone scope que acabamos de criar:

Registro de acesso externo – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “66.56.40.10”

Registro de acesso interno – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “10.10.1.10” –ZoneScope “InternalAccess”

Agora que temos o zone scope e os registros criados, vamos à política que irá diferenciar acessos internos e externos:

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainPolicy” –Action Allow –ServerInterface “eq,10.10.1.100” –ZoneScope “InternalAccess,1” –ZoneName uilson.net

Feito!!!! Temos agora nosso ambiente direcionando as requisições internas ao site produtos.uilson.net para o back-end server interno e os acessos externos indo diretamente para o servidor externo, conforme definido no escopo inicial.

Poderiamos dizer que temos o trabalho finalizado, certo? Errado! Deixar o ambiente simplesmente como está pode, em alguns casos, criar uma vulnerabilidade que precisa ser mitigada.

Lembre-se que neste exemplo temos um DNS Server resolvendo nomes para recursos internos e externos. O que pode ocorrer aqui é que requisições internas e externas passem fazer queries por endereços de internet, podendo expor o ambiente a um Reflection Attack ou DNS Amplification Attack – um DDoS.

Neste caso, as resoluções recursivas para nomes externos precisa ser bloqueada e para isso criaremos outra política que vem a ajudar na mitigação desta vulneravbilidade:

image

Desenho original do link: https://blogs.technet.microsoft.com/networking/2015/05/12/split-brain-dns-deployment-using-windows-dns-server-policies/

O link que postei sobre DDoS DNS Amplification Attack pede que a funcionalidade da recursiva seja desasbilitada no servidor DNS. Neste caso, vamos desabilitar este recurso que será usado somente para requisições internas.

Desabilitando a recursiva: Set-DnsServerRecursionScope –Name . –EnableRecursion $False

No comando acima, a recursiva está sendo desabilitada para o escope default (tudo que está em uilson.net).

Agora vamos habilitar a recursiva somente para um escopo de clientes internos:

Add-DnsServerRecursionScope –Name “RecursionInternalClients” –EnableRecursion $True

Agora vamos criar a política que irá permitir a recursiva somente para clientes internos;

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainRecursionInternal”-Action ALLOW –ApplyOnRecursion –RecursionScope “RecursionInternalClients” –ServerInterfaceIP “EQ,10.10.1.100”

Agora temos nosso ambiente executando dentro de uma melhor prática para o recurso do Split-Brain DNS.

Espero mais uma vez que o conteúdo possa ser útil e não perca o volume 5 desta série. Iremos falar sobre Filtering com DNS Policies.

Abraços

Uilson

Sobre DNS Policies–Windows Server 2016–volume 03–Gerenciamento de Tráfego de Rede baseado em Geo-Localização

25 de abril de 2017 Deixe um comentário

Saudações,

Dando continuidade a série de posts sobre DNS Policies no Windows Server 2016, vamos hoje ao volume 03 onde falaremos sobre o gerenciamento de tráfego de rede baseado em geo-localização via políticas de DNS com PowerShell. Para quem chegou agora, os links para os dois primeiros posts:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Vamos ao cenário – Você tem uma aplicação de intranet que está instalada em 4 servidores em sua rede. Cada servidor está em uma filial da empresa (São Paulo, Rio de Janeiro, Belo Horizonte e Fortaleza). As requisições vindas dos usuários de São Paulo deverão acessar o servidor da própria localidade, da mesma forma que os demais Estados. Imagine que a Intranet de São Paulo foi desenvolvida para os usuários da localidade, logo um usuário de Fortaleza não pode acessar o conteúdo paulista. O mesmo se dá com BH e Rio. Entenderam? Acho que sim né?

Subnet de São Paulo – 10.10.1.0/24

Subnet do Rio de Janeiro – 10.10.2.0/24

Subnet de Belo Horizonte – 10.10.3.0/24

Subnet de Fortaleza – 10.10.4.0/24

Endereço da intranet – https://intranet.uilson.net

O processo tem que ocorrer de acordo com o desenho abaixo:

 

image

Agora que temos o cenário pronto e descrito, vamos a parte técnica. Como fazer com que as requisições via DNS para esses servidores de aplicação sejam encaminhadas da forma como definimos no começo deste post? Simples! Vamos de PowerShell!

Como no post anterior, vamos repetir alguns passos para fixar os conceitos criando zone scopes, subnet scopes, inserir registros nos zone scopes e criar a regra que faz essa distribuição.

Apenas relembrando, para se instalar o serviço de DNS via PowerShell, seja integrado ao AD ou avulso, através de um Zone File, você pode consultar o post que escrevi da série de otimização de tarefas com PowerShell sobre DNS Server.

Estou assumindo neste laboratório que já temos um DNS Server instalado com um primary zone definido – no nosso laboratório é o domínio uilson.net.

1. Criação dos Client Subnets

Vamos criar os client subnets que serão utilizados em nossa política de gerenciamento de tráfego de rede. Na imagem abaixo, o comando para criação do client subnet para o ambiente em São Paulo:

image

Agora vamos repetir o processo para os demais sites do nosso ambiente de laboratório:

Add-DnsServerClientSubnet -Name RJSubnet -IPv4Subnet 10.10.2.0/24

Add-DnsServerClientSubnet –Name BHSubnet -IPv4Subnet 10.10.3.0/24

Add-DnsServerClientSubnet -Name CESubnet -IPv4Subnet 10.10.4.0/24

Com o comando Get-DnsServerClientSubnet você consegue ver a lista de client subnets criada.

2. Criação dos Scope Zones e adição do registro

Agora que temos nossos client subnet´s criados, vamos repetir um passo ensinado no 2o. post desta série que foi a criação dos escopos de zona (Zone Scopes) para que as requisições que vierem de qualquer uma das subnets criadas possam ser atendidas pelo registro que estiver no escopo correspondente a localidade em que o usuário se encontra.

Abaixo o comando para criação do escope zone em São Paulo no nosso laboratório:

image

No exemplo acima, eu criei um Zone Scope chamado “SPZoneScope_NM” (SP Zone Scope – Network Management) – somente para diferenciar do que foi criado no artigo anterior. Lembrando que o nome o Scope é o de sua conveniência. Apenas estou esclarecendo para que está acompanhando a série de posts desde o inicio.

Agora vamos repetir o processo para as outras localidades:

Add-DnsServerZoneScope -Zonename uilson.net -Name RJZoneScope_NM

Add-DnsServerZoneScope -Zonename uilson.net –Name BHZoneScope_NM

Add-DnsServerZoneScope -Zonename uilson.net -Name CEZoneScope_NM

Agora vamos inserir um registro em cada um desses Zone Scopes.

Vamos inserir o registro do tipo “A” chamado “intranet em cada um dos Zone Scopes:

Add-DnsServerResourceRecord -ZoneName uilson.net -A -Name intranet -IPv4Address 10.10.1.10 –ZoneScope SPZoneScope_NM

Add-DnsServerResourceRecord -ZoneName uilson.net -A -Name intranet -IPv4Address 10.10.2.10 –ZoneScope RJZoneScope_NM

Add-DnsServerResourceRecord -ZoneName uilson.net -A -Name intranet -IPv4Address 10.10.3.10 –ZoneScope BHZoneScope_NM

Add-DnsServerResourceRecord -ZoneName uilson.net -A -Name intranet -IPv4Address 10.10.4.10 –ZoneScope CEZoneScope_NM

4. Criação da política de gerenciamento de tráfego de rede

Com as client subnets criadas, zone scopes e registro definidos, vamos a criação da política de gerenciamento do tráfego de rede para a aplicação intranet do nosso laboratório:

image

Para cada localidade uma politica será criada:

Add-DnsServerQueryResolutionPolicy –Name SPPolicy -Action ALLOW -ClientSubnet ‘eq,SPSubnet’ -ZoneScope ‘SPZoneScope_NM,1’ -ZoneName uilson.net

Add-DnsServerQueryResolutionPolicy -Name RJPolicy -Action ALLOW -ClientSubnet ‘eq,RJSubnet’ -ZoneScope ‘RJZoneScope_NM,1’ -ZoneName uilson.net

Add-DnsServerQueryResolutionPolicy –Name BJPolicy -Action ALLOW -ClientSubnet ‘eq,BHSubnet’ -ZoneScope ‘BHZoneScope_NM,1’ -ZoneName uilson.net

Add-DnsServerQueryResolutionPolicy -Name CEPolicy -Action ALLOW -ClientSubnet ‘eq,CESubnet’ -ZoneScope ‘CEZoneScope_NM,1’ -ZoneName uilson.net

Nas políticas acima, a requisição que vem da subnet de São Paulo é direcionada exclusivamente para o servidor registrado no zone scope correspondente, ou seja, de São Paulo. O mesmo ocorrerá com as demais localidades.

5. Conclusão

Esta é apenas uma das formas de se configurar o tráfego de rede via DNS Policies. Nessa série de posts vamos explorar todas as formas disponíveis nesse mesmo laboratório. Vamos voltar a falar sobre gerenciamento de tráfego de rede em outros aspectos nos posts sub-sequentes.

No próximo post vamos falar sobre Split-Brain DNS.

Espero que o conteúdo possa ser útil a suas tarefas diárias e o ajude de forma eficaz.

Abraços

Uilson

Categorias:Não categorizado

Sobre DNS Policies–Windows Server 2016–volume2–Balanceamento de Carga

11 de abril de 2017 Deixe um comentário

Saudações,

Dando continuidade a nossa série de posts sobre DNS Policies, hoje vou relembrar um post que publiquei a um tempo atrás falando sobre o uso do balanceamento de carga de aplicações.

Para quem ainda não leu o primeiro post desta série, segue abaixo o link:

Sobre DNS Policies – Volume1 – Teoria

1. Planejamento do Balanceamento de carga

Vamos clarificar que, o planejamento para alta disponibilidade e sizing de suas aplicações, você não deve somente se basear no que vamos falar aqui. Você precisa ter em mente os objetivos e tipos de acesso que serão necessários para a sua realidade. O balanceamento de carga pode ser feito via NLB Windows, Failover Clustering ou NLB via hardware (este um recurso mais indicado para aplicações que recebem muitos acessos). No caso de high availability em cloud, verifique as questões de elasticidade em termos desenvolvimento e veja como seu cloud provider trabalha em relação a isso.

Enfim, o balanceamento de carga via DNS Policies deve ser avaliado quanto sua eficácia para o negócio que seu aplicativo visa entregar a um departamento e/ou cliente final. Você precisa estar certo de que esta é a melhor opção para seu cenário.

2. Estudo de caso

Vamos propor aqui, como no artigo original publicado anteriormente, um estudo de caso que nos dará a base para a solução a ser implementada:

2.1. Tenho 4 servidores de aplicação – 1 em São Paulo, 1 no Rio de Janeiro, 1 em Fortaleza e  1 em Belo Horizonte

2.2. Fortaleza e Belo Horizonte possuem links com menos banda que SP e RJ

2.3. Essa aplicação vai atender a todo acesso que vier em qualquer uma das filiais da empresa

3. Cenário

Para atender a esta demanda, temos o seguinte desenho de solução:

 

image

4. Solução técnica

Com o exposto acima, vamos ver agora de forma prática como o DNS Policies nos ajuda a entregar essa solução de forma rápida e tudo via PowerShell!!

Primeiro vamos criar os escopos de zona. É a partir deles que a política vai se orientar para aplicar o que queremos. Para cada localidade onde tenho um servidor de aplicação vou crirar um Scope Zone.

Vou noema-los da seguinte forma:

São Paulo: SP_Scope

Rio de Janeiro: RJ_Scope

Fortaleza: For_Scope

Belo Horizonte: BH_Scope

Como fica as linhas de comando PowerShell para isso:

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “SP_Scope”

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “RJ_Scope”

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “For_Scope”

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “BH_Scope”

image

Com os Scope Zones criados, vou criar um registro tipo A dentro destes escopos, ou seja, cada escopo estará apontando para o IP do back-end server da localidade correspondente:

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.0.10” –ZoneScope “SP_Scope”

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.1.10” –ZoneScope “RJ_Scope”

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.2.10” –ZoneScope “For_Scope”

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.3.10” –ZoneScope “SP_Scope”

image

Agora que já temos os Zone Scopes criados e seus respectivos registros, vamos criar a política que fará o balanceamento de carga via DNS Policies:

Add-DnsServerQueryResolutionPolicy -Name "AppServerPolicy" -Action ALLOW – -ZoneScope "SP_Scope,3;RJ_Scope,3;For_Scope,2;BH_Scope,2" -ZoneName "uilson.net"

image

No comando acima observa-se que ao fim de cada Scope Zone foi colocado uma vírgula e um número (Ex: SP_Scope,3). Isto vai definir que para a cada 10 requisições feitas para o host “appserver.uilson.net”, teremos as 3 primeiras sendo direcionadas para o servidor em São Paulo, as próximas 3 para o servidor do Rio de Janeiro, as 2 seguintes para o servidor em Fortaleza e as 2 últimas para o servidor de Belo Horizonte. Dessa forma conseguimos balancear a carga entre as 3 localidades, respeitando os limites de link de cada uma delas.

5. Conclusão

Este post foi publicado novamente para seguir a série que começamos em 03/abril/2017 sobre DNS Policies. No próximo post falaremos sobre Gerenciamento de tráfego de Rede usando políticas de DNS.

Espero que você tenha gostado e que este conteúdo possa ajuda-lo em suas tarefas diárias.

Abraços

Uilson

Sobre DNS Policies–Windows Server 2016–volume 1–Teoria

3 de abril de 2017 Deixe um comentário

Saudações,

Falando em termos de Windows Server 2016 podemos citar, além de sua total integração e adequação à nuvem também aspectos on-premisses que vão aumentar muito a produtividade de seu datacenter em matéria de Segurança.

Vamos começar hoje uma série de posts voltados a DNS Policies no Windows Server 2016. Nas primeiras versões do ainda recém-divulgado SO Windows Server 2016 TP fiz um laboratório neste espaço acerca do balanceamento de carga de aplicações usando DNS Policies. Vou republicar este post para que a comunidade possa rever o tema e fica como o primeiro de uma série que iremos tratar.

palestra_preview

No que tange à Segurança da Informação levando em mente alguns dos seus principais pilares (Integridade, Disponibilidade e Confidencialidade), o DNS Policies traz possibilidades interessantes de expansão da capacidade de resolução de nomes.

De que forma e como posso configurar DNS Policies? Veja abaixo como:

1. Application Load Balance – Ao implementar vários nodes em uma farm de servidores de aplicação – seja IIS ou outro web server (ou até mesmo um client server) – o DNS Policies pode ser usado para balancear o tráfego entre os nodes desta farm. Diferente do antigo recurso de Round Robin o balanceamento do DNS Policies distribui a carga de forma dinâmica e mais inteligente podendo priorizar um ou mais nodes em relação ao direcionamento das requisições.

2. Gerenciamento de tráfego baseado em Geo-Localização – Para as requisições baseadas em localização geográficas o DNS Policies faz com que servidores DNS primário e secundário fazem o cliente ser redirecionado para o IP do recurso mais próximo, otimizando o tráfego e consumo de banda, dependendo da localização do destino.

3. Split Brain DNS – Com o recurso de Split Brain DNS os registros são divididos em diferentes escopos de zona no mesmo servidor DNS. Os clientes DNS recebem uma resposta baseado onde de fato estes clientes estão – internos ou externos. Este recurso pode ser configurado em zonas integradas ao AD ou para DNS Standalone servers.

4. Filtering – Neste caso você cria filtros de critérios baseados em requisitos definidos na criação da política propriamente dita, ou seja, a resposta de um DNS Server ocorrerá de acordo com a maneira que um cliente faz a query.

5. Foresincs – Um dos recursos que mais gostei nessa parte de políticas. Você pode fazer com que seu DNS redirecione requisições maliciosas para um IP não existente ao invés de direcioná-la para o computador que ela tenta alcançar.

6. Redirecionamento baseado na hora do dia – Vem como uma adicional à política de gerenciamento de tráfego. Você pode direcionar a requisição para um determinado local baseado em uma hora do dia, ou seja, a requisição vai para aquele servidor a partir de um determinado horário do dia.

Novos conceitos

Client Subnet – Um objeto Client Subnet representa uma range IP (IPv4 ou IPv6) a qual as queries são submetidas em um servidor DNS. Você pode criar client subnet’s que vão ser usadas em políticas de DNS que vai resolver/encaminhar uma requisição a um determinado destino baseado na range de IP definida em uma subnet client. Exemplo: Clientes da subnet 10.10.1.0/24 serão encaminhados ao node 2 da farm de servidores de aplicação, enquanto clientes da subnet 10.10.2.0/24 serão encaminhados ao node 1 da minha farm de servidores.

Recursion Scope – Um escopo de recursão contém uma lista de Forwarders e especifica se a recursão está ativada. Um DNS Server pode ter diversos recursion scopes e as políticas atreladas a ele irão ser direcionadas para o escopo que contemple aquela query. Você pode especificar quais forwarders serão utilizados e se utilizarão a recursão.

Zone Scopes – Um DNS Server pode ter diversos escopos de zona (Zone Scopes) contendo neles uma lista de registros. Um mesmo registro pode estar presente em diversos escopos de zona, com diferentes endereços IP. Políticas de Zone Transfer são feitas usando os escopos de zona.

Os conceitos acima se aplicam aos seguintes tipos de política: Query Resolution Policies, Recursion Policies, Zone Transfer Policies, Traffic Management, Block Queries from a Domain, Block Queries from a Subnet, Allow Recursion for Internal Clients, Create a Server Level Zone Transfer Policy, e finalmente, Create a Zone Leve Zone transfer Policy.

No decorrer desta série de posts veremos em exemplos práticos com PowerShell como usar todas as políticas citadas acima em seu ambiente. Não perca! Certamente ela vai ajudar bastante seu dia a dia para assimilar melhor essa nova funcionalidade no Windows Server 2016.

Em breve a parte de balanceamento de carga com DNS Policies será republicada.

A base de estudos para este post foi tirada do link abaixo:

https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview

Abraços

Uilson

Usando PowerShell para corrigir vulnerabilidades via chave de registro

28 de março de 2017 Deixe um comentário

Saudações,

O post de hoje visa ajudar os administradores de rede e analistas de segurança no momento em que precisam planejar a mitigação e correção de alguns tipos de vulnerabilidades em estações de trabalho via chave de registro.

Normalmente, a empresa dispõe de uma ferramenta que faz o scan, encontra, classifica e exibe em relatório quais vulnerabilidades uma ou mais estações têm e como corrigir.

Agora, imaginem uma determinada vulnerabilidade a ser corrigida em diversas estações? Como fazer?

Uma forma é usar o comando PSEXEC do SysInternals para executar este trabalho. A partir de um arquivo de lote eu uma simples variável (%1), o problema pode ser resolvido. Entretanto, como nosso foco é disseminar todas as formas de otimização de tarefas com PowerShell, queria mostrar como o usei para resolver um problema num case real.

Recebemos a notificação de que uma determinada área da empresa precisava ter todas as estações com o parâmetro de SMB Signing habilitado. Este parâmetro criptografa todo fluxo de informações entre a estação e um file server, num processo semelhante ao do SMB Encryption, feito no Windows Server 2012 R2, entretanto, o processo aqui visa proteger estações com Windows 7 Professional.

Não existe uma console administrativa ou um processo via GUI para tal, portanto, como falei, ou você o faz via PSEXEC do SysInternals ou, no nosso caso, usando PowerShell.

O processo consiste na criação de uma chave de registry que vai habilitar o SMB Signing na estação:

Chave a ser criada – EnableSecuritySignature

Tipo – DWORD

Valor – 1

Endereço – HKLM\System\currentcontrolset\services\lanmanworkstation\parameters

Comando PowerShell a ser usado:

Invoke-Command -cn computername {New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters" -Name EnableSecuritySignature -Value "1" -PropertyType DWORD -Force | Out-Null}

No comando acima, criamos a chave de registry remotamente em uma estação. Estou considerando aqui que o administrador tem amplo acesso ao equipamento remoto. Entretanto você pode se deparar com um ambiente em que seu usuário não tenha acesso àquela estação (ou grupo de estações) e precise declarar seu usuário. Neste caso você pode entrar com o seguinte comando:

$Auth = Get-Credential dominio\usuario
Invoke-Command -cn computername -Cred $Auth {New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters" -Name EnableSecuritySignature -Value "1" -PropertyType DWORD -Force | Out-Null}

Ao executar este comando, você será solicitado a entrar com o usuário e senha com permissão de acesso na estação:

image

Ao entrar com as credenciais necessárias, o script faz criação da chave com o valor conforme citado acima.

Você pode conferir se a chave foi mesmo criada usando comando abaixo:

Invoke-Command -cn computername {Get-Item -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters"}

Abaixo o resultado:

image

Agora vamos considerar o fato de termos uma lista de estações a serem corrigidas. Como fazer? Você pode usar o PowerShell ISE e criar um script para isso, usando laços do comando For EACH:

ForEach ($WKS in (Get-Content C:\ComputerList.txt)){
    Invoke-Command -cn $WKS {New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters" -Name EnableSecuritySignature -Value "1" -PropertyType DWORD -Force | Out-Null}
    }

Antes de executar o script acima, você precisa preencher o TXT citado na primeira linha e preencher com os nomes das estações. O processo será realizado em cada uma delas.

Espero que o conteúdo seja útil e ajude no seu dia a dia.

Abraços

Uilson

Criação e adequação em contas de parceiros externos via PowerShell

6 de março de 2017 Deixe um comentário

Saudações,

Neste primeiro post de 2017 vou compartilhar com vocês um trabalho feito a uns dias atrás na empresa onde trabalho.

Cenário – Uma consultoria foi contratada para dar suporte a uma aplicação on-premisses da empresa. O contrato tem duração da data de hoje até 31 de dezembro de 2017. Como se trata de uma solução de ERP instalada em um de nossos servidores, ficou acertado que 4 pessoas desta consultoria deveriam ter acesso como Administrator neste servidor para as devidas manutenções, migrações, etc. Entretanto, não posso simplesmente criar 4 novas contas no domínio e coloca-las como administrator de um servidor. Alguns critérios tiveram que ser seguidos para que as normas de segurança definidas pelo nosso time de Cyber Security não fossem quebradas.

Vou neste post mostrar como fiz, usando alguns exemplos em meu ambiente de laboratório.

Descrição do ambiente:

Domínio: uilson.net

Nome da empresa que vai alocar consultores: 123 Consultoria SA

Passos a serem seguidos na tarefa:

1. Criar uma OU específica para provedores externos

New-ADOrganizationalUnit -Name "ExternalProviders" -Path "DC=uilson,DC=net" -Description "OU para contas de usuários externos"

Acima criei a OU “ExternalProviders” que irá abrigar as OU´s de todos os meu parceiros externos que alocam pessoas em minha organização

2. Criar uma OU dentro daquela criada no item 1 descrevendo o nome da empresa

New-ADOrganizationalUnit -Name "123Consultoria" -Path "OU=ExternalProviders,DC=uilson,DC=net" -Description "OU para contas da 123 consultoria SA"

Acima criei a OU “123Consultoria” que vai ficar dentro da OU “ExternalProviders”.

3. Criar as contas de usuário já dentro dessa nova OU, definindo a senha provisória, solicitando alteração de senha no log on do usuário e seguindo as melhores práticas de segurança definir que cada conta será desabilitada em 31/12/2017

New-ADUser -Name "José da Silva 123 Consultoria" -SamAccountName jose.silva -UserPrincipalName jose.silva.ext@uilson.net -DisplayName "Jose da Silva – consultor externo" -Description "Usuário Consultor da 123 Consultoria" -Title "Jose da Silva – 123 Consultoria" -Enable $true -ChangePasswordAtLogon $true -AccountPassword (ConvertTo-SecureString "!!!zaq12wsx" -AsPlainText -force) -PassThru -Path "OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net" | Set-ADAccountExpiration -DateTime "12/31/2017"

O comando acima cria o usuário “jose.silva” com uma senha pré-definida que deverá ser alterada no momento do primeiro log on do usuário, a localização da conta (dentro das OU´s que criamos anteriormente) e para casos como este de usuários externos, definição da data de expiração da conta, ou seja, o projeto ao que este usuário está alocado deverá se encerrar até 31/12/2017, data qual a conta será desabilitada.

O mesmo poderá ser repetido com outros usuários desta mesma empresa que vierem a integrar o quadro de consultores externos.

Agora vamos supor que o gestor do contrato com a “123 Consultoria” lhe peça pra listar a data de expiração da conta do consultor “José da Silva”, apenas para ter certeza de que a configuração de expiração da conta bate com a data final do contrato:

get-aduser jose.silva -Properties * | Select-Object Name,SamAccountName,AccountExpirationDate

No comando acima você receberá o seguinte resultado:

image

Vimos na imagem acima que a criação do usuário foi feita de forma a respeitar os processos de segurança da informação da empresa e também certifica que, em 31/12/2017 a conta do usuário listado não mais funcionará a partir da meia noite do dia citado.

Agora seu gerente quer saber quais são os recursos da “123 Consultoria” alocados na empresa. Sabendo qual a OU em que esses usuários estão criados você já pode fazer uma linha de comando mais elaborada:

Get-ADUser –Filter * –SearchBase “OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net” | Select-Object Name,SamAccountName

Executando o comando acima você tem o resultado abaixo

image

Você pode mandar essas informações para seu gerente no corpo do email ou simplesmente  envie para um arquivo TXT e trate depois em um excel, basta incluir “> arquivo.txt” no fim da linha de comando exemplificada acima.

Depois de alguns dias, você recebe uma notificação de sua gestão dizendo que, pela complexidade do projeto no qual a 123 Consultoria está atuando, o tempo de contrato foi extendido, ou seja, não mais acabará em 31/12/2017 e sim em 31/12/2018. Dessa forma, os acessos da equipe alocada precisa continuar em funcionamento após a primeira data estipulada.

Neste caso você não precisa efetuar a alteração conta por conta. Simplesmente aplique o update para toda a OU “123Consultoria”:

O primeiro comando fará com que todos os usuários da 123 Consultoria tenham sua data de expiração alterada para 31/12/2018:

Get-ADUser -Filter * -SearchBase "OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net" | Set-ADAccountExpiration -DateTime "12/31/2018"

Agora você pode tirar a prova para se certificar que a alteração foi feita usando o comando abaixo:

Get-ADUser -Filter * -SearchBase "OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net" -Properties * | Select-Object Name,SamAccountName,AccountExpirationDate

Os comandos acima trazem o resultado na figura abaixo:

image

Com base na imagem acima, e tendo em mente os usuários externos da empresa, vamos para nosso último laboratório deste post. Depois de alguns meses de trabalho, o gerente da equipe de desenvolvimento entendeu que a consultora Hele de Jesus (userid – helena.jesus) desempenha um excelente trabalho no suporte ao produto ERP da empresa e lhe faz uma proposta de contratação como funcionária efetiva. A mesma aceita e agora vai fazer parte do quadro de funcionários.

Com todas as formalidades em dia, você da área de infra estrutura recebe uma solicitação para adequar o usuário de Helena ao padrão da empresa, ou seja, tem que mover a conta para a OU “DevTeam” que fica dentro de “ITDept”, mudar as descrições da conta e remover a data de expiração da conta, afinal, Helena agora é funcionária nossa!

Dessa vez vamos usar o editor de script´s PowerShell ISE, lembrando que para abrir este editor você apenas precisa digitar “ise” no prompt de comando do PowerShell. Como vamos rodar vários comandos, resolvi definir uma varíavel para o usuário “helena.jesus”. Veja como ficou abaixo:

$conta = "helena.jesus"
Get-ADUser $conta | Clear-ADAccountExpiration
Get-ADUser $conta |  Move-ADObject -TargetPath "OU=DevTeam,OU=ITDept,DC=uilson,DC=net"
Set-ADUser $conta -DisplayName "Helena de Jesus" -Description "Desenvolvedora ITDept" -Department "IT Department" -UserPrincipalName "helena.jesus@uilson.net" -Title "Helena de Jesus"

O script acima fica assim no ISE:

image

Após execução do Script, ainda vemos que um atributo permanece inalterado, conforme image abaixo:

image

O campo “Name” não foi alterado, permanece como “Helena de Jesus 123 Consultoria”. Isso ocorre porque este campo fica na propriedade DistinguishedName do usuário “helena.jesus”. Para que este campo seja renomeado corretamente, é preciso alterar o objeto “CN” do DistinguishedName. Abaixo mostro dois comandos, sendo o primeiro para listar o DistinguishedName do usuário e o segundo mostro como fazer a alteração necessária:

get-aduser helena.jesus | Select-Object distinguishedname

Rename-ADObject -Identity "CN=Helena de Jesus 123 Consultoria,OU=DevTeam,OU=ITDept,DC=uilson,DC=net" -NewName "Helena de Jesus"

image

Na tela acima você vê os resultados da aplicação dos comandos.

Agora o objeto aparece corretamente no AD:

image

Além disso, vemos que os procedimentos adotados removeram a data de expiração da conta:

image

Neste post vimos como configurar acessos no Active Directory para consultores externos seguindo as melhores práticas de segurança e todos os

Espero que possa ser útil no dia a dia de vocês.

Quero pedir desculpas pela demora em postar neste ano. Estou estudando para as provas da CompTIA. Vou começar com Cloud Essentials (o livro vc pode comprar no link no lado superior direito). Depois vou estudar Security+, depois vem Cloud+ e CSA (Cyber Security Analyst) – você pode ter uma visão geral de todas essas certificações em https://certification.comptia.org/pt/certificações

Seguiremos este ano com posts voltados a todo tipo de otimização de tarefas com PowerShell, Web Application Proxy e Azure AD Application Proxy.

Abraços

Uilson

%d blogueiros gostam disto: