Uso de dns-suffix para redirecionamento informativo

Para acessar esta opção devemos ir até a opção Blackhole Domains, localizada no painel esquerdo dentro de Resolvers. E a partir daí clicar no botão +RPZ-Policy.

../../_images/2-add-suffix.png

Em vez de bloquear um domínio com NXDOMAIN, pode-se configurar uma política do tipo add-suffix que permita redirecionar o usuário para uma página informativa (por exemplo, um portal governamental).

../../_images/3-add-suffix.png

Este mecanismo funciona em duas partes:

  1. Configuração no resolver (RPZ): Define-se uma política do tipo add-suffix na seção Blackhole Domains. Por exemplo, diante de uma consulta para badsite.com, o resolver responderá com um CNAME como:

    badsite.com.prohibited.domain.com.
    
  2. Configuração na zona DNS do domínio receptor: Na zona prohibited.domain.com, deve ser criada a seguinte entrada wildcard:

    * IN A xxx.xxx.xxx.xxx <--(ip del servidor web)
    

    Isto garante que qualquer subdomínio como badsite.com.prohibited.domain.com resolva para o IP do servidor web que gerenciará o redirecionamento.

  3. Configuração do servidor web (nginx): No servidor web que responde em xxx.xxx.xxx.xxx, deve ser criado um vhost do nginx que capture qualquer subdomínio sob prohibited.domain.com e redirecione para o site desejado.

    A seguir é mostrado um exemplo completo do nginx.conf:

    server {
        listen 80;
        server_name .prohibited.domain.com;
        location / {
            return 301 https://government-portal.com;
        }
    }
    
    server {
        listen 443 ssl;
        server_name .prohibited.domain.com;
        ssl_certificate     /etc/nginx/ssl/fullchain.pem;
        ssl_certificate_key /etc/nginx/ssl/privkey.pem;
        location / {
            return 301 https://government-portal.com;
        }
    }
    

Com esta configuração, os usuários que tentarem acessar domínios proibidos serão redirecionados para uma página explicativa, em vez de receber simplesmente um erro DNS.

Configurar o certbot para a geração de certificados

São detalhados os passos a seguir no Debian para a geração de certificados SSL para serem utilizados no Nginx

apt install certbot

Instalar um servidor em um IP, por exemplo 1.2.3.4

Criar um registro A de servidor.dominio.com apontando para 1.2.3.4

Criar um registro CAA contendo «issue 0 letsencrypt.org»

sudo certbot certonly --standalone -d servidor.dominio.com

A porta 80 deve estar liberada no firewall

Executar:

systemctl list-timers | grep certbot

Isto é para garantir que exista um timer de renovação do certbot.

Editar o seguinte arquivo:

/etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Dentro desse arquivo colocar:

#!/bin/bash
cp /etc/letsencrypt/live/servidor.dominio.com/fullchain.pem /etc/ssl/certs/fullchain.pem
cp /etc/letsencrypt/live/servidor.dominio.com/privkey.pem /etc/ssl/private/privkey.pem
systemctl reload nginx

Aviso

NÃO configurar a porta 80 no nginx, pois ela é utilizada pelo certbot letsencrypt.

Dentro do nginx configurar:

server {
    listen 443 ssl;
    server_name ~^(.+\.)*servidor\.dominio\.com$;

    ssl_certificate     /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;

    return 301 https://servidor.dominio.com$request_uri;
}


server {
    listen 443 ssl http2;
    server_name servidor.dominio.com;

    ssl_certificate     /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256';
    ssl_prefer_server_ciphers on;

    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    location / {
       root /var/www/html;
       index index.html index.htm;
       }
 }