El sitio es accesible en la dirección IP cuando no se sigue la guía de instalación

Contribuir Característica
1

Por seguridad, creo que sería mejor que, por defecto, los foros de Discourse no sean visibles al navegar directamente a la dirección IP en un navegador.

Un par de razones:

  • Permite usar el sitio sin HTTPS, tanto para los usuarios como para la configuración inicial por parte del administrador.
  • Filtra la dirección del servidor de origen, lo cual es malo si estás usando Cloudflare o algo similar para proteger tu IP de origen de ataques DDoS o intentos de hackeo al servidor, especialmente si los hackers consideran que el servidor es de alto valor. Hay personas que ejecutan bots que escanean todos los rangos de IP propiedad de proveedores de alojamiento web.

Además, el instalador de Discourse ahora confirma que el dominio o subdominio está configurado correctamente; de lo contrario, no continuará con la instalación.

Todo lo que se necesita agregar al final del archivo /etc/nginx/conf.d/discourse.conf (dentro del contenedor Docker) es:

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

Donde 1.1.1.1 es la dirección IP pública de tu servidor. Probablemente haya una forma más elegante de incluir la dirección IP que codificarla directamente. Probé un par de opciones pero no logré que funcionaran.

Funciona bien para mí (incluso con la proxy de Cloudflare); no puedo pensar en muchos casos en los que permitir el acceso web directamente a la IP sea útil o necesario. Parece una práctica bastante común deshabilitarlo. ¡Estoy abierto a escuchar cualquier razón en contra de hacerlo!

1 me gusta
2

¿Por qué hacer algún cambio si nuestra guía predeterminada te deja con un sitio que funciona solo con HTTPS?

Las personas con necesidades especiales pueden ir y hacer modificaciones, pero nuestra configuración predeterminada se mantendrá tal como está, usando por defecto un nombre de dominio funcional y HTTPS.

9 Me gusta
3

¡Muchas gracias!

1 me gusta
4

Hablando objetivamente, esto no es exacto. No es solo HTTPS, ya que puedes acceder al sitio directamente a través de la dirección IP que no usa HTTPS.

La diferencia radica en deshabilitar las conexiones inseguras sin HTTPS y exponer la IP de origen del servidor. No conozco ningún beneficio en eso.

Si realizas una consulta DNS de los 50 sitios más importantes del mundo, parece que ninguno de ellos es accesible de forma insegura directamente a través de la IP. No creo que sea irrazonable asumir que los 50 sitios más importantes del mundo están utilizando las mejores prácticas.

Aquí tienes una lista bastante precisa de los sitios más populares:

Aquí tienes una herramienta de consulta DNS:

5

Por defecto, intentar acceder mediante IP devolverá un 301 Redirect al dominio correcto:

$ 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/

Al

¿Tu propuesta es cambiar de un 301 a un 404?

3 Me gusta
6

8 de 8 instalaciones, realizadas usando la imagen de Digital Ocean: Communiteq (anteriormente DiscourseHosting) instalada (y luego migrada), así como manualmente siguiendo esta guía discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub. Todas son accesibles de forma insegura mediante la dirección IP de forma predeterminada. Dos de ellas se instalaron la semana pasada (usando la guía de GitHub mencionada anteriormente).

¿Quizás hay un paso adicional que estoy pasando por alto? Diría que un error 404 es mejor que una redirección 301, ya que probablemente la mayoría de las personas que exploran las direcciones IP no tienen intenciones buenas. Pero una redirección 301 es mejor que el acceso inseguro.

7

No se puede reproducir..

http://38.242.24.122 me redirige correctamente a https://discourse.codinghorror.com/

4 Me gusta
8

Hmmm, quizás sea la plantilla de Cloudflare. Eso es probablemente la única diferencia consistente con una instalación totalmente limpia entre todas ellas.

1 me gusta
9

Si has tomado medidas que no están listadas en la instalación de Cloud, por definición no es una «instalación vanilla».

La plantilla de Cloudflare no hace nada obvio para interferir con una redirección:

run:
  - file:
      path: /tmp/add-cloudflare-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # Descargar lista de IPs de CloudFlare
        wget https://www.cloudflare.com/ips-v4/ -O - > /tmp/cloudflare-ips
        wget https://www.cloudflare.com/ips-v6/ -O - >> /tmp/cloudflare-ips
        # Convertir a comandos de nginx y escapar para incluirlos en el comando sed append
        CONTENTS=$(</tmp/cloudflare-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
        
        echo IPs de CloudFlare:
        echo $(echo | sed "/^/a $CONTENTS")
        # Insertar en discourse.conf
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header CF-Connecting-IP;" /etc/nginx/conf.d/discourse.conf
        # Limpiar
        rm /tmp/cloudflare-ips

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

Obtiene los rangos de IP, los almacena temporalmente como cloudflare-ips y agrega soporte para CF-Connecting-IP.

2 Me gusta
10

Correcto. No afirmé que fueran “instalaciones vanila”.

Así que probé eliminando la plantilla oficial de Cloudflare en una de ellas y luego reconstruyéndola; lamentablemente, no marcó diferencia. Todavía es accesible de forma insegura mediante la dirección IP.

Realmente no se me ocurre nada más fuera de lo común entre esas instalaciones. Los únicos plugins en esa instancia eran el gestor de Docker incluido por defecto y el plugin oficial de anuncios. Está en la rama estable, pero los otros sitios que también se comportan igual están en una mezcla de estable, beta y pruebas superadas.

11

No es específico de ninguna configuración, ni de Cloudflare, simplemente otro dato y punto de vista:

Podemos configurar un proxy para redirigir una “dirección IP desnuda en el puerto 80” (como ejemplo) a cualquier otro FQDN de varias maneras, tanto con Apache2 como con Nginx.

Hay muchas formas de hacerlo (reescribir y redirigir, host virtual y redirigir, etc.).

Por ejemplo, podemos crear un host virtual en un proxy inverso donde el proxy inverso escuche la dirección IP en el puerto 80 y redirija todas esas solicitudes a cualquier FQDN (o dirección IP) que elijamos.

También podemos hacerlo con un proxy inverso utilizando mod_rewrite en Apache2 y reglas de reescritura en Nginx.

Para todas nuestras configuraciones de Discourse (en operaciones), tenemos un proxy inverso frente a Discourse (algunos Apache2, otros Nginx) y es fácil mitigar este tipo de problemas (a medida que surgen) configurando el proxy inverso para manejar estos casos y situaciones especiales.

Dicho esto, no utilizo el caso especial de Cloudflare como proxy, pero parece que cualquier proxy podría configurarse para gestionar este tipo de problemas, al igual que cualquier proxy inverso puede configurarse para redirigir “casi cualquier cosa a cualquier otra cosa”.

Llevando esto un paso más allá, si fuera un usuario comercial de proxy (como Cloudflare) y tuviera una dirección IP o nombre de dominio específico que quisiera redirigir (o bloquear), configuraría (o solicitaría) al proxy (en este caso Cloudflare) que redirija la “dirección IP desnuda en el puerto 80” al FQDN (o a donde sea) que elija.

Este es el tipo de cosas para las que están diseñados los proxies (por diseño); y como se mencionó, este tipo de redirección es fácil de hacer con Apache2 o Nginx, por lo que asumo (no siendo un usuario de Cloudflare) que un servicio comercial como Cloudflare puede gestionar este tipo de redirección trivial con facilidad.

3 Me gusta
12

Yo uso esto para un sitio para redirigir a los bots que lo atacan por IP cruda a una 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;
        }
}

PERO estoy de acuerdo con los demás al decir que no puedo reproducir el acceso por IP en mi foro privado tampoco. Recibo la redirección. Y el mío no tiene configuración especial, no usa Cloudflare, y literalmente está ejecutando un servidor virtual de $0 al mes que no me ofrece lujos.

3 Me gusta
13

Pero si lo piensas, te darás cuenta de que todos tienen configuraciones con balanceo de carga en una infraestructura que cuesta (decenas de) millones de dólares. Así que tampoco son representativos.

La migración no copia ninguna configuración de nginx, así que en realidad se trata de una instalación nueva.

2 Me gusta
14

¡Genial, gracias por compartir ese fragmento @elijah, lo aprecio! Cambiaré la IP codificada en tu expresión regular o usaré el fragmento completo. :slight_smile:

2 Me gusta
15

Sí, eso refuerza la idea de que es muy probable que esos sitios no sean accesibles directamente por IP en la web. De todos modos, nadie parece apoyar permitir el acceso directo inseguro por IP en la web.

Sí, tienes razón.

1 me gusta
16

Acabo de probar el lanzamiento de 2 instancias de Discourse en Digital Ocean utilizando su aplicación del mercado para lanzarlas rápidamente.

Quería probar esto con prácticamente cero configuración personalizada, solo editando smtp, dev_email y discourse_hostname con datos falsos (para permitir la reconstrucción).

El instalador se detiene debido a que el dominio/subdominio ficticio que configuré no supera la etapa de validación de dominio (y recomienda editar manualmente el archivo app.yml y luego reconstruir).

Después de editar el archivo app.yml y reconstruir (solo smtp, dev_email y discourse_hostname), el sitio está disponible de forma insegura en la dirección IP sin ninguna intervención de Cloudflare. No redirige al discourse_hostname configurado.

La mayoría de mis instalaciones no utilizaron la aplicación del mercado de Digital Ocean para configurarse, sino que se realizaron manualmente siguiendo la guía estándar de instalación con Docker.

Cabe destacar que el instalador se detuvo por no poder validar el dominio también en dos instalaciones recientes que utilicé con Cloudflare, probablemente debido al proxy. Las otras instalaciones se realizaron antes de que hubiera una etapa de validación de dominio en el instalador.

edición: Nota de que solo 2 de las 8 instalaciones de Discourse tuvieron algún problema de verificación de dominio durante la instalación inicial (sin incluir las dos instancias de prueba mencionadas anteriormente). El script de configuración de Discourse sugiere al usuario editar manualmente el archivo app.yml y reconstruir en caso de error de verificación de dominio. No hay problema si esto no es útil, ya que no fue una solución para mí.

edición: Generalmente se utiliza Cloudflare con SSL flexible, no letsencrypt (lo cual sería mejor). Gracias @neounix.

17

FYI @markersocial

Todas nuestras instalaciones de Discourse redirigen http://la.ip.add.res a https://FQDN configurado mediante LETSENCRYPT habilitado en el archivo .yml del contenedor de Discourse.

Para que todo funcione correctamente y los certificados LETSENCRYPT operen, necesitas una configuración SSL completamente funcional (normalmente con LETSENCRYPT), como ya debes saber.

Solo un recordatorio… espero que esto ayude.

2 Me gusta
18

Vanilla tiene un dominio válido y está utilizando el script de configuración de Discourse.

Si no haces ninguna de estas dos cosas, no es inesperado que el resultado sea diferente.

Este tema no contiene información accionable y no podemos reproducirlo si se siguen las instrucciones.

7 Me gusta