Hardening – Blindando seu Registro.BR

Hardening

Atualmente quando se fala em blindagem, ou Hardening (termo técnico utilizado para descrever a técnica de fortificação do seu ambiente), muitos se esquecem que a segurança do ambiente web começa pelo registro do domínio. Não é raro encontrar ambientes que, mesmo tendo passado por testes de intrusão, hardening ou auditoria, são mantidos fragilizados nesse ponto, permanecendo com sua segurança comprometida.

Já temos vários casos de crimes que ocorreram abusando de fragilidades deixadas no registro do domínio.

É bastante comum encontrarmos domínios registrados no registro.br sob a propriedade de outra pessoa que não tem ligação nenhuma com a empresa. Pode ser algum técnico de TI que efetuou o registro, um amigo webmaster, ou que “entende de informática”. Muitas vezes uma pessoa que não tem os devidos cuidados ao utilizar os acessos privilegiados que possui.

É importante saber que um domínio é como um bem qualquer, um automóvel ou um imóvel. Quem constar como proprietário deste domínio no registro.br será o proprietário do nome da sua empresa na internet.

Uma pessoa mal intencionada, explorando configurações fragilizadas, pode alterar os servidores de DNS e apontar para servidores próprios, ou “ownados” (do inglês owned, como dizemos no nosso dia a dia), passando a receber seus e-mails, incluindo alertas de segurança ou mudança de senha de redes sociais e outros acessos que, inevitavelmente, apontamos para os nossos e-mails, que acabam se tornando o nosso ponto de convergência digital. Estamos falando aqui especialmente daquele e-mail que recebemos quando clicamos no link “esqueci minha senha”.

Lembre-se que algumas das configurações de cadastro do registro.br são individuais. Se você tiver vários domínios, precisará adequar em todos, revisando o registro de cada um deles.

Em virtude disso, aplico um hardening nos domínios, que consiste basicamente nos seguintes passos:

  1. Ter um monitoramento validando se ele está no ar, vencendo, ou se sofreu alguma alteração (de IDs ou DNSs por exemplo). Eu uso o Nagios. Motivo: você saberá antes do prazo do registro vencer, ou se alguma alteração ocorrer, imediatamente.
  2. Usar senhas complexas e únicas, além de ativar MFA (Autenticação de Múltiplos Fatores), em qualquer ID/conta de registros de domínios. Motivo: Boas práticas com senhas, duplo fator em todas elas. Use um bom cofre de senhas e decore apenas a senha do cofre (eu uso keepassxc.org, ele tem um “authenticator” interno, assim você não fica dependendo sempre do telefone).
  3. Criar IDs diferentes para cada função específica (Contato do Titular, Contato Administrativo, Contato Técnico e Contato Cobrança). Motivo, você pode perder acesso a um deles, ou precisar delegá-los a alguém, principalmente em grandes empresas.
  4. Criar grupos com as pessoas que devem ser alertadas em cada Contato criado. Motivo: Mais de uma pessoa receberá alertas, além disso, no caso de um spear phishing (ataque direcionado), fica mais difícil para o atacante saber quem é o alvo para personalizar o ataque.
  5. Colocar estes grupos como e-mail de contato de cada respectivo Contato no registro.br. Motivo: Qualquer comunicação será recebida por todo o grupo. A idéia é que não se saiba quem é o destinatário e mais de uma pessoa esteja atenta. Sugiro também que estes grupos sejam utilizados somente para este fim, pois desta forma temos mais consciência que só deveríamos receber mensagens enviadas por entidades de registro, assim se receber de outro tipo de remetente poderá ser ignorado. Em tempo: No grupo de cobrança coloque alguém da área técnica também, pois a pessoa de cobrança pode não saber identificar os boletos de registro de domínio falsos.
  6. Um dos grupos (eu sugiro o Contato da Entidade) não deve pertencer ao mesmo domínio que está sendo registrado, nem conter somente e-mails do domínio, se for mais de um, melhor. Motivo: Caso os DNSs ou servidores de e-mail sejam comprometidos você ainda tem uma chance de acessar, alterar ou resetar os acessos e configurações, pois as mensagens chegarão neste e-mail “de fora” do domínio em questão.
  7. O Contato de Entidade deve ficar sob dupla custódia (ex: uma pessoa possui a senha e outra possui o token). Motivo: Como são acessos de alto privilégio, é melhor que mais de uma pessoa tenha que ser acionada para quaisquer alterações, ou criação de novos domínios. Visto que o mais usado é sempre o Contato Administrativo e o Contato Técnico, não causará grandes transtornos esse passo a mais no processo de uso do Contato da Entidade, mas vai agregar um nível de segurança bem maior.
  8. Fiquem atentos aos alertas enviados aos grupos criados para esse fim. Perdendo o acesso a algum ID, o ID superior deverá logar e removê-lo dos contatos. Motivo: não adianta colocar cães para latir e não ir verificar quando alertarem ;-))).
  9. Use DNSSec, esse recurso faz com que seus visitantes web possam “conferir” se o endereço IP entregue como sendo o seu domínio é o verdadeiro, similar ao certificado SSL, porém atua no momento da resolução do nome. Motivo: Isso minimiza muito a chance do visitante do seu site ou aplicação, ser desviado para um site falso (clonado), ataque bem comum nos dias de hoje.
  10. Utilize múltiplos servidores de DNS em regiões diferentes. Se o seu provedor não oferece este recurso, utilize os servidores do próprio registro.br. Motivo: Disponibilidade. Se você estiver com os dois DNSs no mesmo local e ocorrerem problemas de acesso a eles, você ficará fora do ar. O registro.br oferece esse serviço gratuito, com DNSSec por padrão.
  11. Utilize nomes genéricos, exemplo: idtecnico@, webmaster@. Motivo: Para dificultar os ataques de engenharia social contra os times envolvidos.
  12. Tenha uma cópia das entradas DNSs guardadas (backup). Motivo: Você nunca sabe quando vai precisar delas 😉

Exemplo de um whois com hardening aplicado:

Domínio insight.inf.br

Ingisht Solution Team Informática ME
07.931.740/0001-90
Sérgio Baroukh
BR
INSTE6
INSTE37
INSTE38
INSTE36
a.sec.dns.br
b.sec.dns.br
15956 RSASHA1 F300725CEC0B7CE54C26A5A72DC9DB4F2B6785F2
09/03/2005 #2042396
09/03/2019
14/03/2018
Publicado

Contato (ID) INSTE6

Insight Solution Team
ist_id_entidade@googlegroups.com
BR
23/09/2009
27/09/2017

Contato (ID) INSTE36

Insight Solution Team
id_cobranca@insight.inf.br
BR
27/09/2017
27/09/2017

Contato (ID) INSTE37

Insight Solution Team
id_admin@insight.inf.br
BR
27/09/2017
27/09/2017

Contato (ID) INSTE38

Insight Solution Team
id_tecnico@insight.inf.br
BR
7/09/2017
A27/09/2017

Abraço!
Amilton Justino
Insight Solution Team
PGP Key ID 01AD6182

0 respostas

Deixe uma resposta

Quer entrar na discussão?
Sinta-se livre para contribuir!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

This site uses Akismet to reduce spam. Learn how your comment data is processed.