O site é acessível pelo endereço IP quando não se segue o guia de instalação

Contribuir Funcionalidade
1

Por segurança, acho que seria melhor se, por padrão, os fóruns do Discourse não fossem visíveis ao acessar diretamente o endereço IP em um navegador.

Algumas razões:

  • Permite o uso do site sem HTTPS, tanto para usuários quanto para a configuração inicial pelo administrador.
  • Vaza o endereço do servidor de origem, o que é ruim se você estiver usando o Cloudflare ou algo similar para proteger seu IP de origem contra ataques DDoS ou tentativas de invasão de servidor, caso os hackers considerem o servidor de alto valor. Existem pessoas rodando bots que varrem todos os intervalos de IP pertencentes a provedores de hospedagem.

Além disso, o instalador do Discourse agora confirma se o domínio/subdomínio está configurado corretamente; caso contrário, ele não prossegue com a instalação.

Tudo o que precisa ser adicionado ao final do arquivo /etc/nginx/conf.d/discourse.conf (dentro do contêiner Docker) é:

server {
    listen 80;
    server_name 1.1.1.1;
    server_tokens off;
    return 404;
}

Onde 1.1.1.1 é o endereço IP público do seu servidor. Provavelmente existe uma maneira mais elegante de incluir o IP do que codificá-lo diretamente. Tentei algumas opções, mas não consegui fazê-las funcionar.

Funciona bem para mim (inclusive com proxy do Cloudflare). Não consigo pensar em muitos casos em que permitir acesso web direto ao IP seria útil ou necessário. Parece ser uma prática bastante comum proibir isso. Mas estou aberto a ouvir argumentos contra essa medida!

1 curtida
2

Por que fazer alguma mudança se nosso guia padrão deixa você com um site funcionando apenas com HTTPS?

Pessoas com necessidades especiais podem ir e mexer no código, mas nosso padrão permanecerá como está, configurando automaticamente um nome de domínio funcional e HTTPS.

9 curtidas
3

Muito obrigado!

1 curtida
4

Falando objetivamente, isso não é preciso. Não é apenas HTTPS, pois você pode acessar o site diretamente via o endereço IP que não é HTTPS.

A diferença é desabilitar conexões inseguras sem HTTPS e expor o IP de origem do servidor. Não tenho conhecimento de nenhum benefício nisso.

Se você fizer uma consulta DNS aos 50 principais sites do mundo, parece que nenhum deles é acessível de forma insegura diretamente via IP. Não acho que seja irracional assumir que os 50 principais sites do mundo estão usando as melhores práticas.

Aqui está uma lista dos principais sites bastante precisa:

Aqui está uma ferramenta de consulta DNS:

5

Por padrão, tentar acessar via IP resultará em um redirecionamento 301 para o domínio correto:

$ curl 159.203.68.6 -I
HTTP/1.1 301 Moved Permanently
Server: nginx/1.16.1
Date: Mon, 29 Jun 2020 20:24:41 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
Location: https://falcoland.falco.dev/

Ao

Sua proposta é mudar de um 301 para um 404?

3 curtidas
6

De 8 instalações, todas feitas usando a imagem do Digital Ocean, o Communiteq (antigo DiscourseHosting) foi instalado (e depois migrado), bem como manualmente seguindo este guia discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub. Todas são acessíveis de forma insegura via IP por padrão. Duas delas foram instaladas na última semana (usando o guia do GitHub acima).

Será que há algum passo extra que estou perdendo? Eu diria que um 404 é melhor que um 301, já que provavelmente a maioria das pessoas vasculhando os endereços IP não tem boas intenções. Mas um 301 é melhor que acesso inseguro.

7

Sem reprodutibilidade…

http://38.242.24.122 redireciona corretamente para https://discourse.codinghorror.com/

4 curtidas
8

Hmmm, talvez seja o modelo do Cloudflare. Essa provavelmente é a única diferença consistente em relação a uma instalação totalmente padrão entre todos eles.

1 curtida
9

Se você tomou medidas que não estão listadas na instalação padrão da Cloud, isso não é, por definição, uma “instalação vanilla”.

O modelo da Cloudflare não faz nada óbvio para interferir em um redirecionamento:

run:
  - file:
      path: /tmp/add-cloudflare-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # Baixar lista de IPs da CloudFlare
        wget https://www.cloudflare.com/ips-v4/ -O - > /tmp/cloudflare-ips
        wget https://www.cloudflare.com/ips-v6/ -O - >> /tmp/cloudflare-ips
        # Converter para comandos nginx e escapar para inclusão no comando de append do sed
        CONTENTS=$(</tmp/cloudflare-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
        
        echo IPs da CloudFlare:
        echo $(echo | sed "/^/a $CONTENTS")
        # Inserir no discourse.conf
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header CF-Connecting-IP;" /etc/nginx/conf.d/discourse.conf
        # Limpar
        rm /tmp/cloudflare-ips

  - exec: "/tmp/add-cloudflare-ips"
  - exec: "rm /tmp/add-cloudflare-ips"

Ele obtém os intervalos de IP, armazenados temporariamente como cloudflare-ips, e adiciona suporte ao CF-Connecting-IP.

2 curtidas
10

Certo. Eu não afirmei que eram “instalações vanilla”.

Então, testei remover o modelo oficial do Cloudflare em um deles e depois recriar. Infelizmente, não fez diferença. Ainda é acessível de forma insegura via IP.

Não consigo pensar em nada fora do comum entre essas instalações. Os únicos plugins naquela instância eram o gerenciador de Docker incluído por padrão e o plugin oficial de anúncios. Está na branch estável, mas os outros sites que se comportam da mesma forma estão em uma mistura de estável, beta e testes aprovados.

11

Não é específico para nenhuma configuração ou Cloudflare, apenas mais um ponto de dados e perspectiva:

Podemos configurar um proxy para redirecionar um “endereço IP nu na porta 80” (como exemplo) para qualquer outro FQDN de várias maneiras, tanto com o Apache2 quanto com o Nginx.

Existem muitas formas de fazer isso (reescrita e redirecionamento, host virtual e redirecionamento, etc.).

Por exemplo, podemos criar um host virtual em um proxy reverso, com o proxy reverso ouvindo o endereço IP na porta 80, e redirecionar todas essas solicitações para qualquer FQDN (ou endereço IP) que escolhermos.

Também podemos fazer isso com um proxy reverso usando o mod_rewrite no Apache2 e regras de reescrita no Nginx.

Em todas as nossas instalações do Discourse (em produção), temos um proxy reverso na frente do Discourse (alguns Apache2, outros Nginx), e é fácil mitigar esse tipo de problema (conforme surgem) configurando o proxy reverso para lidar com esses casos e situações especiais.

Dito isso, eu não uso o caso especial do cloudflare como proxy, mas parece que qualquer proxy seria configurável para gerenciar esse tipo de problema, assim como qualquer proxy reverso pode ser configurado para redirecionar “praticamente qualquer coisa para qualquer outra coisa”.

Dando um passo além, se eu fosse um usuário comercial de proxy (como a Cloudflare) e tivesse um endereço IP ou nome de domínio específico que quisesse redirecionar (ou bloquear), configuraria (ou solicitaria) que o proxy (neste caso, a Cloudflare) redirecionasse o “endereço IP nu na porta 80” para o FQDN (ou para onde quer que eu escolha).

Esse é o tipo de coisa que os proxies foram projetados para lidar (por design); e, como mencionado, esse tipo de redirecionamento é fácil de fazer com o Apache2 ou o Nginx, então presumo (não sendo um usuário da Cloudflare) que um serviço comercial como a Cloudflare possa gerenciar esse tipo de redirecionamento trivial com facilidade.

3 curtidas
12

Eu uso isso em um site para redirecionar bots que acessam por IP bruto para uma página especial:

server {
        listen 80;
        # listen [::]:80;

        server_name ~^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+;

        root /var/www/ip-address;
        default_type text/plain;
        index nothing.doing;
        location / {
                try_files $uri /nothing.doing;
        }
}

MAS eu concordo com os outros ao dizer que não consigo reproduzir o acesso por IP no meu fórum privado também. Recebo o redirecionamento. E o meu não tem configuração especial, nem Cloudflare, e está literalmente rodando em um servidor virtual de $0 por mês que não oferece recursos extras.

3 curtidas
13

Mas, se você pensar bem, pode perceber que todos eles têm configurações de balanceamento de carga em uma infraestrutura que custa (dezenas de) milhões de dólares. Portanto, eles também não são representativos.

A migração não copia nenhuma configuração do nginx, então, na verdade, isso é apenas uma nova instalação.

2 curtidas
14

Ótimo, obrigado por compartilhar esse trecho, @elijah, agradeço! Vou substituir o IP fixo pela sua expressão regular ou usar o trecho completo. :slight_smile:

2 curtidas
15

Sim, isso reforça a ideia de que esses sites provavelmente não são acessíveis via web por meio de qualquer IP direto. De qualquer forma, ninguém parece apoiar a permissão de acesso direto inseguro via IP na web.

Sim, você está certo.

1 curtida
16

Acabei de testar a inicialização de 2 instâncias do Discourse no Digital Ocean usando o aplicativo do marketplace deles para lançá-las rapidamente.

Queria testar isso com configuração personalizada quase zero, apenas editando o smtp, o e-mail de desenvolvimento e o discourse_hostname com dados falsos (para permitir a reconstrução).

O instalador para devido ao domínio/subdomínio falso que configurei, que não passou na etapa de validação de domínio (e recomenda editar o arquivo app.yml manualmente e depois reconstruir).

Após editar o app.yml e reconstruir (apenas smtp, e-mail de desenvolvimento e discourse_hostname), o site está disponível de forma insegura no endereço IP, sem qualquer envolvimento do Cloudflare. Ele não redireciona para o discourse_hostname configurado.

A maioria das minhas instalações não usou o aplicativo do marketplace do Digital Ocean para configuração, mas foi feita manualmente usando o guia padrão de instalação do Docker.

Note que o instalador parando devido à incapacidade de validar o domínio também ocorreu em duas instalações recentes que fiz usando o Cloudflare, provavelmente por causa do proxy.

edição: observe que apenas 2 das 8 instalações do Discourse tiveram algum problema de verificação de domínio durante a instalação inicial (não incluindo as duas instâncias de teste criadas acima). O script de configuração do Discourse sugere que o usuário edite o app.yml manualmente e reconstrua em caso de erro de verificação de domínio. Não há problema se isso não for útil, pois não foi uma solução para mim.

edição: Geralmente uso o SSL flexível do Cloudflare, não o letsencrypt (que seria melhor). Obrigado @neounix.

17

FYI @markersocial

Todas as nossas instalações do Discourse redirecionam o http://the.ip.add.res para o https://FQDN configurado pelo LETSENCRYPT ativado no arquivo .yml do contêiner do Discourse.

Para que tudo funcione corretamente e os certificados do LETSENCRYPT funcionem, você precisa de uma configuração SSL totalmente funcional (normalmente com LETSENCRYPT), como você certamente já sabe.

Apenas um lembrete… espero que isso ajude.

2 curtidas
18

O Vanilla possui um domínio válido e está usando o script de configuração do Discourse.

Se você não fizer nenhum dos dois, não é inesperado que o resultado seja diferente.

Este tópico não contém informações acionáveis e não conseguimos reproduzir o problema se as instruções forem seguidas.

7 curtidas