Tag: network

  • Configuração do nginx como proxy reverso para WordPress, Nextcloud e Proxmox

    Nenhuma das publicações sobre instalação de WordPress ou Nextcloud aborda acesso via HTTPS ou certificados SSL, apenas HTTP.

    Acontece que isso é centralizado em uma instalação do nginx, atuando como proxy reverso. O servidor que hospeda o nginx e o servidor de OpenVPN são a mesma máquina: um VPS com 512mb de RAM e 1vCPU.

    O nginx recebe as requisições em HTTPS e as encaminha em HTTP* de forma segura para os outros servidores – clientes da VPN: WordPress, Nextcloud e Proxmox – 3 máquinas diferentes.

    * Proxmox usa HTTPS por padrão mas com um certificado verificado por uma CA interna

    Vantagens:

    • só é necessário gerenciar os certificados em um servidor, independente de quantos sites são.
    • as 3 máquinas diferentes poderiam estar em qualquer rede, qualquer lugar – isso é, se não fossem virtualizadas dentro do Proxmox, podendo até ser uma rede residencial que bloqueia tráfego de entrada (muito obrigado, Claro), basta se conectar na VPN.

    Desvantagem:

    • existe um pouco de latência devido à distância entre as máquinas (Rio de Janeiro) e o VPS (São Paulo).

    Ainda que fosse possível abrir as portas na rede e o OpenVPN não fosse necessário, usar o nginx como um proxy reverso na mesma LAN ainda poderia ser vantajoso pelo o gerenciamento centralizado dos certificados SSL, logs de acesso e uso de múltiplos nomes de domínio em diferentes servidores pro mesmo IP na mesma porta.

    Os arquivos de configuração do nginx para cada site devem ficar localizados em /etc/nginx/sites-available e para habilitá-los basta criar um symlink em /etc/nginx/sites-enabled com:

    # ln -s /etc/nginx/sites-available/sua_config /etc/nginx/sites-enabled/

    A primeira configuração recomendada é para receber a solicitação HTTP na porta 80 e redirecionar o cliente para fazer uma solicitação HTTPS na porta padrão 443.

    server {
        listen 80 default_server;
        server_name _;
        return 301 https://$host$request_uri;
    }

    Em todos os exemplos de configuração abaixo, substitua o nome do servidor (FQDN), o caminho para o certificado e chave SSL e o IP privado para onde deve ser encaminhada a solicitação.

    Como mencionado, é possível usar a mesma porta para todos os servidores, como a porta padrão HTTPS, desde que cada um tenha o parâmetro server_name diferente, cada um com um nome de domínio (FQDN).

    Configuração para o Proxmox:

    upstream proxmox {
        server "seuproxmox.dominio.com";
    }
    
    server {
        listen 443 ssl;
        listen [::]:443 ssl;
        server_name seuproxmox.dominio.com;
        ssl_certificate /etc/letsencrypt/live/seu.dominio.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/seu.dominio.com/privkey.pem;
        proxy_redirect off;
        location / {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_pass https://10.8.0.2:8006;
            proxy_buffering off;
            client_max_body_size 0;
            proxy_connect_timeout  3600s;
            proxy_read_timeout  3600s;
            proxy_send_timeout  3600s;
            send_timeout  3600s;
        }
    }

    Para o Nextcloud:

    server {
        listen 443 ssl;
        listen [::]:443 ssl;
        ssl_certificate /etc/letsencrypt/live/seu.dominio.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/seu.dominio.com/privkey.pem;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        add_header X-Content-Type-Options "nosniff";
        server_name seunextcloud.dominio.com;
        location / {
            proxy_pass http://10.8.0.3;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_redirect off;
        }
        send_timeout 1800;
    }

    Configurações adicionais são recomendadas no lado do servidor Nextcloud, no arquivo /var/www/nextcloud/config/config.php

      'trusted_proxies' =>
      array (
        0 => '10.8.0.1',
      ),
      'overwritehost' => 'seunextcloud.dominio.com',
      'overwriteprotocol' => 'https',
      'overwritecondaddr' => '^10\\.8\\.0\\.1$',
      'overwritewebroot' => '/',
      'overwrite.cli.url' => 'https://seunextcloud.dominio.com',

    Para o WordPress:

    server {
        listen 443 ssl;
        listen [::]:443 ssl;
        ssl_certificate /etc/letsencrypt/live/seu.dominio.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/seu.dominio.com/privkey.pem;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        add_header X-Content-Type-Options "nosniff";
        server_name seuwordpress.dominio.com;
        location / {
            proxy_pass http://10.8.0.4;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_redirect off;
        }
        send_timeout 1800;
    }

    Configurações adicionais são requeridas no lado do servidor do WordPress, no arquivo /var/www/html/wp-config.php

    define('WP_HOME', 'https://seuwordpress.dominio.com');
    define('WP_SITEURL', 'https://seuwordpress.dominio.com');
    
    if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
        $_SERVER['HTTPS'] = 'on';
    }
    
    if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
        $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
    }

    Sugestão de configuração adicional para o WordPress – o WordPress não tem um mecanismo de proteção contra tentativas de acesso por força bruta. Para mitigar isso, além de usar boas senhas, você pode limitar o acesso por IP às localizações /wp-admin e /wp-login.php na configuração do proxy reverso adicionando essa configuração:

    server {
        location ~* ^/(wp-admin|wp-login.php) {
            allow 186.205.1.165;    # seu IP de casa
            allow 191.252.110.50;    # seu IP do trabalho
            deny all;
            proxy_pass http://10.8.0.4;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }

    Por conveniência, você também pode fazer o nginx escutar pra solicitações a HTTP na porta 80 e redirecionar todos os clientes para uma solicitação HTTPS:

    server {
        listen 80 default_server;
        server_name _;
        return 301 https://$host$request_uri;
    }

    Após configurado, inicie o serviço.

    # systemctl enable --now nginx

    Caso ainda não tenha certificados SSL válidos, eles podem ser obtidos gratuitamente com a Let’s Encrypt, uma organização sem fins lucrativos, com o comando certbot. Primeiro, pare o serviço nginx, já que o certbot vai criar um processo que também vai escutar na porta 80. Então, use o comando nesse formato:

    # certbot certonly --standalone -d seu.dominio.com -d seunextcloud.dominio.com -d seuproxmox.dominio.com -d seuwordpress.dominio.com

    Siga os prompts do programa e, ao terminar, inicie o nginx.service novamente.

    Caso esteja usando o proxy reverso para servidores dentro de uma VPN, você pode querer ver isso aqui.

  • Instalação do FreeRADIUS integrado com Active Directory

    RADIUS é um protocolo de rede que oferece gerenciamento centralizado de autorização e autenticação para acesso de usuários a serviços de rede. Muito usado, por exemplo, como uma alternativa mais segura de acesso a uma rede Wi-Fi, onde cada usuário usa suas credenciais para se conectar, em vez de todos compartilharem uma única senha.

    FreeRADIUS é um sistema livre e aberto que implementa esse protocolo e pode ser configurado pra usar diferentes back-ends para autorização e autenticação, um deles é o Active Directory.

    Pra configurar esse sistema, garanta antes que o servidor RADIUS possa encontrar e ingressar no domínio – aqui tratado como exemplo.com:

    • Domínio e o controlador de domínio podem ser encontrados por consulta de DNS e são acessíveis na rede.
    • O arquivo /etc/hosts do servidor deve conter o FQDN especificado, algo como:
    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    192.168.0.10 radius-server.exemplo.com radius-server

    Após isso, instale e configure o Samba, que vai ser usado para ingressar o computador no domínio. A partir daqui, as instruções são válidas para sistemas da família Red Hat, tendo sido usado o CentOS Stream 9.

    # dnf install samba

    Adapte a configuração abaixo para o seu domínio, alterando ou adicionando os seguintes parâmetros no arquivo /etc/samba/smb.conf :

    [global]
        workgroup = EXEMPLO
        security = ads
        winbind use default domain = yes
        realm = EXEMPLO.COM
    
        idmap config * : backend = tdb
        idmap config * : range = 10000-19999
    
        idmap config EXEMPLO : backend = rid
        idmap config EXEMPLO : range = 20000-99999
    

    Remova também o parâmetro a seguir para evitar o risco de conflito na autenticação:

    [global]
        passdb backend = tdbsam

    Verifique se há algum erro na sua configuração com

    # testparm

    Agora, para ingressar o servidor no domínio:

    # net ads join -U Administrator

    Instale o pacote samba-winbind-clients, habilite o serviço winbind e teste a autenticação com ntlm_auth:

    # dnf install samba-winbind-clients
    # systemctl enable --now winbind.service
    # ntlm_auth --request-nt-key --username=daniel --password='senhaqueanoteinoblocodenotas'

    Um output como

    :  (0x0)

    indica sucesso.

    Agora que o servidor já faz parte do domínio e conseguimos autenticar usuários com ntlm_auth, podemos instalar os pacotes do FreeRADIUS para então configurá-lo

    # dnf install freeradius freeradius-utils

    Pra autenticação no AD, vamos usar a combinação de protocolos PEAP/MSCHAPv2.

    Edite a o módulo mschap localizado em /etc/raddb/mods-enabled/mschap para alterar as seguintes configurações

    mschap {
        use_mppe = yes
        require_encryption = yes
        require_strong = yes
        ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"
    }

    Edite o módulo eap localizado em /etc/raddb/mods-enabled/eap para alterar a seguinte configuração:

    eap {
        default_eap_type = peap
    }

    Dica: os arquivos de configuração do FreeRADIUS são extensivamente comentados. Isso é ótimo porque ajuda a entender a configuração já na hora. Mas se quiser ver só a configuração, sem os comentários e linhas em branco:

    $ grep -vE '^\s*#|^\s*$' /caminho/para/arquivo.txt

    Na pasta /etc/raddb/certs, execute o arquivo bootstrap para gerar os certificados necessários para o TLS usado no PEAP.

    Adicione o usuário radiusd ao grupo wbpriv para que o FreeRADIUS tenha acesso para ler a resposta do winbind à solicitação de autenticação, através do socket em /var/lib/samba/winbindd_privileged/pipe

    # usermod -aG wbpriv radiusd

    Abra as portas necessárias no firewall:

    # firewall-cmd --permanent --add-port=1812/udp
    # firewall-cmd --permanent --add-port=1813/udp
    # firewall-cmd --reload

    E agora basta iniciar o serviço radiusd:

    # systemctl enable --now radiusd.service

    Você pode testar a autenticação pelo FreeRADIUS com

    radtest -t mschap daniel senhaqueanoteinoblocodenotas localhost 0 testing123

    e configurar outros clientes do FreeRADIUS em /etc/raddb/clients.conf

    Alguns clientes podem não aceitar o certificado gerado com as configurações padrão do FreeRADIUS, então é recomendado ajustar as configurações pra que o certificado seja emitido corretamente para o FQDN do servidor. O Easy RSA também pode ajudar a gerar e manter os certificados.

  • Criação de um domínio com Active Directory no Windows Server

    Active Directory Domain Services é um serviço proprietário desenvolvido pela Microsoft usado para gerenciamento centralizado de um domínio de rede em ambientes corporativos, controlando a autorização e autenticação de usuários e computadores, atribuindo e impondo políticas de segurança e instalando ou atualizando softwares.

    Felizmente eu tinha um snapshot da máquina virtual anterior à criação do meu domínio e pude refazer os passos pra colocar umas imagens, porque eu sou uma negação em PowerShell.

    O sistema usado foi o Windows Server 2025 Standard. Antes de instalar o AD DS e criar o domínio, é necessário configurar o sistema com um endereço de IP fixo. Para isso, vá em

    Control Panel > Network and Internet > Network and Sharing Center > Change adapter settings

    Clique com o botão direito no adaptador de rede e clique em Propriedades. Selecione “Internet Protocol Version 4” e clique em Propriedades.

    Configure um endereço de IP estático fora da faixa do DHCP e use o mesmo IP ou 127.0.0.1 para servidor de DNS – que será configurado mais à frente.

    No Server Manager, vá em “Add roles and features”. No Wizard, selecione “Role-based or feature-based installation” e prossiga.

    Na próxima etapa, selecione o seu servidor e prossiga. Em seguida, você vai ver uma lista do que pode ser instalado. Selecione “Active Directory Domain Services” e “DNS Server”.

    O servidor precisará atuar também como servidor de DNS para que clientes possam encontrar e participar do domínio. Esse papel poderia ser delegado a outro servidor de DNS que você tenha configurado no mesmo domínio.

    Na etapa de confirmação, mantenha desmarcada a opção de reiniciar o servidor após instalação, já que só faremos isso após promover o servidor a controlador do domínio.

    Após a instalação, um sinal de atenção vai aparecer nas notificações do Server Manager, onde vai aparecer a opção de promover o servidor a controlador de domínio.

    Isso vai abrir um novo Wizard. Na primeira etapa, selecione “Add a new forest” e determine o seu domínio. Em um caso ideal, você tem nome de domínio público, como exemplo.com, e pode configurar com um subdomínio do tipo ad.exemplo.com. Alternativamente, você pode usar um como privado. Apenas tenha cuidado com possíveis conflitos com domínios externos, escolha algo como exemplo.interno.

    Sobre o nível funcional da floresta e domínio no próximo passo: isso é sobre compatibilidade de funcionalidades e protocolos. Caso não tenha outros controladores de domínio com versões antigas do Windows Server atuando, prossiga com o padrão (mais recente).

    Determine sua senha para o modo de restauração (DSRM). Isso é como o modo de segurança nas versões do Windows Home ou Pro, mas específica para controladores de domínio. Isso porque a autenticação através do AD é desabilitada no modo de restauração, então essa é a senha que você usa pra logar no Administrator.

    Pule a etapa de delegação de DNS, já que estamos configurando nosso servidor de DNS junto com o domínio.

    O nome de domínio NetBIOS é determinado automaticamente a partir do seu nome de domínio totalmente qualificado (FQDN).

    Após isso, siga com as opções padrões até o fim da instalação, onde seu servidor será reiniciado e promovido a controlador de domínio.

    Para que outros computadores possam encontrar o seu domínio e participar dele, você deve alterar as configurações de DHCP do seu roteador para usar seu Windows Server como servidor de DNS.

    Você pode gerenciar usuários e grupos do domínio com dsa.msc, políticas de grupo com gpmc.msc, e o servidor de DNS com dnsmgmt.msc.

    Sugestão de segurança: Princípio do menor privilégio.
    Por padrão, só administradores podem incluir ou remover computadores do domínio. Pra resolver isso você pode criar um usuário ou grupo e delegar as permissões do contêiner Computers em “Active Directory Users and Computers” (dsa.msc).