¿Es seguro usar * sin autenticación * para servicios que solo escuchan en localhost?

Podrían intentar falsificar 127.0.0.1 (no estoy seguro de si la tarjeta de red lo aceptaría o no, no deberían, pero quién sabe si cada configuración maneja esto correctamente), pero incluso si pudieran, no lo harían. t obtener una respuesta, siempre que sea un webui. Posiblemente sea un problema para las conexiones UDP, pero las solicitudes web no son UDP.

La mayor preocupación sería que si un atacante alguna vez tuviera algún nivel de acceso local a su servidor, podría acceder a sus servicios con mayor facilidad. Por ejemplo, si pudieran obtener algún tipo de proxy en su servidor, tendrían acceso completo, ya que podrían comportarse como localhost.

Si obtienen acceso completo al servidor, es probable que tenga una conexión con el sistema de todos modos, pero la autenticación en los servicios, especialmente si se usa para proteger los almacenes de datos, podría limitar el daño de un servidor comprometido.

  

¿Es posible que un atacante de alguna manera falsifique 127.0.0.1 y obtenga acceso?

No que yo sepa.

Sin embargo, cualquier aplicación que se ejecute en su máquina puede tener acceso a servicios vinculados a localhost . Ejecutar una aplicación maliciosa o comprometida puede estar fuera de su modelo de amenaza, pero vale la pena señalarlo. Es probable que si alguien tuvo acceso a su máquina, entonces lo que pueda pasar con sus torrents puede ser irrelevante.

Una característica del kernel de Linux llamada Filtrado de ruta inversa cae o registra paquetes que vienen en una interfaz (en este caso, red) donde la respuesta debe ir en una interfaz diferente (en este caso, bucle invertido).

Un entorno de servidor típico tiene muchos niveles de privilegios para usuarios y servicios que se ejecutan en ese servidor. Lo que sea que tenga acceso local en ese servidor, tiene acceso a su bucle de retorno y los servicios no autenticados que se ejecutan en él. Una cuenta de invitado puede tener privilegios de archivo mínimos, pero tiene el mismo privilegio que cualquier otro usuario cuando se trata de acceder a servicios locales.

En un entorno de usuario de escritorio y donde tiene una aplicación web en localhost, entonces alguien que está interceptando su comunicación HTTP de texto claro (definitivamente tiene algo), puede inyectar JavaScript en ella y luego usar su navegador como un proxy para acceder desde adentro. su red y localhost. Lo mismo se aplica cuando usted es víctima de XSS en cualquier aplicación web a la que accede o si su aplicación local es vulnerable a CSRF. Esto se ilustró de manera interesante en una historia reciente y popular llamada Cómo pirateé su enrutador . Y hay otros servicios locales como SMTP que usan comunicación de texto y se puede acceder a través de XSS y CSRF. Los escenarios Man-In-The-Browser también llegarán a sus datos locales.

Hay un ataque bastante poco conocido llamado DNS que se puede volver a enlazar y que se puede usar para explotar una situación como esa. Aquí es un excelente video de Robert "RSnake" Hansen que explica los conceptos básicos. Míralo. Ahora.

... está bien, listo? Entonces, aquí está el escenario: Digamos que usted tiene una IU web para un servicio privado que se ejecuta en 127.0.0.1:80 sin ningún tipo de autenticación que lo proteja. Y supongamos que al servicio no le importan los encabezados de host. En la mayoría de los casos, los tipos de servicios que estaría ejecutando allí no lo harán, al menos no de forma predeterminada.

Introduce Evil Guy. Establece una página web en su servidor en 123.123.123.123:80 y vincula su nombre de dominio, www.evil.com , a la IP. Luego te envía un correo electrónico: "Hey, check out this cool website I found: http://www.evil.com/" . Y tú, sin tener idea de lo que está pasando, abre el enlace. La página muestra un video divertido del gato, pero en el fondo, en realidad hace una solicitud XHR que obliga al nombre de dominio a volver a enlazar a su dirección IP local, 127.0.0.1 .

Ahora hay una página web en http://www.evil.com/ con las secuencias de comandos de Evil Guy que se ejecutan en ella, pero el nombre de dominio en realidad apunta a su interfaz de usuario web privada. Eso significa que los scripts en la página tienen acceso completo a su herramienta interna. Normalmente, la política del mismo origen impediría dicho acceso, pero ahora los protocolos, nombres de dominio y puertos coinciden, por lo que no hay nada que pueda hacer. Y así, estás jodido.

La solución: utilizar la autenticación. O asegúrese de que sus servicios web respeten el encabezado del host y produzcan errores al recibir solicitudes de hosts desconocidos. O, solo para estar seguro, hacer ambas cosas.