¿Qué tan seguro es el enlace con localhost para evitar conexiones remotas?

21

Digamos que estamos ejecutando un servicio que está vinculado a localhost (127.0.0.1), y el objetivo es permitir solo clientes locales (es decir, solo desde la misma máquina)

¿Qué técnicas podrían usarse para romper esta seguridad, hay medidas adicionales que podrían usarse para hacerla cumplir?

    
pregunta davidkomer 24.04.2015 - 10:06
fuente

5 respuestas

18

Lo primero y principal es asegurarse de que el firewall en su host esté configurado para eliminar correctamente los paquetes entrantes con la dirección de origen o destino establecida en 127.0.0.1.

En circunstancias normales, no debería haber ningún paquete proveniente de la red que muestre dichas direcciones. Sin embargo, un atacante puede intentar falsificar dichos paquetes para llegar a sus servicios de escucha locales.

No sé qué tipo de otros servicios están escuchando en su máquina, pero si algún servicio se puede usar como un retransmisor, debe asegurarse de que esté configurado correctamente para evitar transmitir cualquier cosa a los servicios de escucha locales.

Por ejemplo, si tiene un proxy HTTP ejecutándose en este host, un atacante puede usar este proxy para solicitar el host "127.0.0.1": desde la perspectiva del firewall, esta será una conexión legítima proveniente de la red al proxy servicio, y localmente será una comunicación legítima entre dos servicios locales (el proxy y el puerto local de destino). El proxy HTTP aquí es solo un ejemplo, tal técnica también puede funcionar con otros servicios, incluidos los servicios donde las conexiones de retransmisión no son la funcionalidad principal (la El ataque de rebote FTP , por ejemplo, es un ejemplo clásico de dicha amenaza).

    
respondido por el WhiteWinterWolf 24.04.2015 - 10:31
fuente
10

Una posible vulnerabilidad sería comprometer una cuenta / servicio de bajo privilegio y usarla como un pivote para acceder al servicio vinculado al servidor local.

Por lo general, prefiero los sockets UNIX para ese propósito, ya que puede aplicarles permisos de usuario / grupo (que serán manejados de manera transparente por el sistema operativo, el usuario no tendrá que mantener otra contraseña). Además, también son un poco más rápidos, lo que los hace preferibles para IPC en la misma máquina.

Tenga en cuenta que los permisos de socket no siempre se respetan en algunas variantes de UNIX y puede ser necesario un ajuste específico del sistema operativo (como aumentar el número de conexiones permitidas por socket).

    
respondido por el user42178 24.04.2015 - 12:50
fuente
7

Si el servicio proporciona una interfaz web, podría ser vulnerable a ataques CSRF, ataques XSS o secuencias de comandos "mismo sitio" . Todo esto puede activarse simplemente visitando el sitio web externo de los atacantes, que por sí solo puede ser causado por publicidad maliciosa o phishing. Para estos ataques no importa si el servicio está escuchando solo en localhost, ya que solo es necesario que el navegador web local pueda acceder al host. Los mismos problemas existen con atacar hosts de intranet desde afuera.

    
respondido por el Steffen Ullrich 24.04.2015 - 15:35
fuente
1

La respuesta depende de diferentes factores. Algunos que pueden o no pueden aplicarse:

  • ¿Qué protocolo es? (Por ejemplo, UDP es más propenso a los problemas de seguridad en este caso, ya que funciona sin estado y podría lograr algo con un solo paquete falsificado).
  • ¿Consideras ataques o solo acceso a datos? (Consulte más arriba: es posible que pueda realizar un ataque DoS para un servicio UDP defectuoso con un solo paquete, pero no logrará el flujo de datos).
  • ¿Tiene acceso remoto a nivel de usuario (por diseño o como un problema de seguridad en sí mismo)? (Por ejemplo, un usuario puede configurar un túnel SSH).
  • ¿Tiene acceso root remoto (por diseño o como un problema de seguridad en sí mismo)? (Uno podría configurar un NAT para redirigir el tráfico de IP pública a 127.0.0.1)
  • ¿Tiene firewall, el filtro de ingreso está configurado correctamente?
  • ¿Tiene otros servicios de red abiertos en un host no local que puedan ser "engañados" para acceder al servicio local de solo alojamiento en su nombre?
respondido por el Bgs 24.04.2015 - 23:55
fuente
1

También tenga en cuenta que el nombre de host localhost no es exactamente el mismo que el IP 127.0.0.1 (naturalmente, necesita resolverse primero), y en la mayoría de las situaciones depende de una entrada en el archivo hosts o un servidor de resolución / dns capaz de resolver 127.0.0.1. Por lo tanto, asegúrese de que puede especificar estrictamente 127.0.0.1 en lugar de localhost al implementar medidas de seguridad, de lo contrario tendrá que retroceder y también considerar los problemas de seguridad en el resolvedor.

    
respondido por el Jeff Meden 24.04.2015 - 17:05
fuente

Lea otras preguntas en las etiquetas