¿Puede la dirección IP ser un componente de la autenticación de 2 factores?

Pensaría que una dirección IP es "un lugar en el que estás" en lugar de cualquiera de los tradicionales "algo que sabes", "algo que tienes" y "algo que eres" que forman parte de la autenticación de 3 factores.

Aunque las direcciones IP son triviales a la falsificación, las conexiones TCP no lo son y SSH es un protocolo creado sobre TCP. La dirección IP de una conexión TCP es un indicador confiable de a quién está conectado directamente.

Digamos que limito las conexiones SSH solo a la dirección IP de mi oficina, un atacante tendrá que hacer una de estas acciones:

1. Estar en o cerca (si rompe la conexión inalámbrica) mi oficina
2. Esté en el camino entre mi oficina y mi servidor (digamos dentro de nuestro ISP).
3. Controlar una máquina dentro de mi oficina.

El punto 3. permite al atacante estar en cualquier parte del mundo, pero aumenta la dificultad de un ataque.

puntos 1. y 2. reducen significativamente la cantidad de personas que pueden usar los otros factores (como su clave SSH o contraseña) si logran adquirirlos y, por lo tanto, los veo como valiendo la pena.

La calidad de la dirección IP es un factor importante aquí. Utilicé mi oficina como el ejemplo anterior, pero si tiene una dirección IP dinámica, ¿confía en el rango completo que posee su ISP? ¿Cómo afecta eso a lo fácil que es para un atacante obtener una de esas direcciones IP? ¿Cambia la confiabilidad de una dirección IP cuando sabe que hay 10 máquinas ocultas por NAT detrás de ella? ¿Qué pasa si hay 2,000 máquinas y 100 puntos de acceso inalámbrico?

No consideraría que una dirección IP sea un factor por sí solo.

Si se hace correctamente, podría ser una adición algo útil a su protocolo de seguridad. Sin embargo, no me atrevería a utilizarlo para reemplazar un factor preexistente en su autenticación, ya que las direcciones IP no son información secreta (se la regala a cada sitio web que visita) y depende de cómo / dónde las obtenga. Dirección desde, podría ser trivial a spoof. Pero si usa la dirección IP de una conexión TCP junto con, por ejemplo, una cookie segura solo de http almacenada, podría agregar algo de seguridad. Específicamente, invalidaría la cookie cada vez que cambia la dirección IP (que puede cambiar por motivos benignos, como la reasignación de su IP por parte de su ISP) y por motivos maliciosos (el atacante se apoderó de su cookie).

Como dijo Ladadadada , las direcciones IP en las conexiones TCP ya no son fáciles de falsificar. TCP requiere un procedimiento de intercambio para obtener un número de secuencia de 32 bits aleatorio del servidor antes de que pueda intercambiar información. Si usted forja una dirección IP aleatoria completamente falsa al iniciar el procedimiento de intercambio, entonces los paquetes no se enviarán a su computadora a través de Internet, por lo que no puede completar el intercambio. A menos que sea, usted controle los enrutadores intermedios en el ISP o una computadora en una de las mismas redes locales que podrían capturar los paquetes enrutados a otro lugar, en cuyo caso podría falsificar direcciones IP aleatorias.

Sin embargo, si diseña una aplicación web y registra la dirección IP, debe tener cuidado. Supongamos que tiene una aplicación web con dos servidores web (por ejemplo, uno para contenido dinámico / otro para estático), detrás de un equilibrador de carga u otro proxy. Puede ver por prueba y error que la dirección IP del cliente solo está presente en el encabezado HTTP X-Forwarded-For . Sin embargo, este campo es fácil de cambiar. Por ejemplo, telnet www.whatismyip.org 80 y escriba lo siguiente con / sin X-Forwarded-For la línea (recuerde presionar la tecla Intro dos veces después de la última línea para indicar el final de su solicitud HTTP).

GET / HTTP/1.1
Host: www.whatismyip.org
X-Forwarded-For: 1.2.3.4

y verá que esta aplicación web cree que su dirección IP ha cambiado a 1.2.3.4 . Así que asegúrese de probar a fondo. En general, creo que hacer esto por ti mismo es más trabajo de lo que vale, especialmente porque puede frustrar a los usuarios cuyas direcciones IP cambian con bastante frecuencia.

EDITAR: Me di cuenta después de escribir esto que, si bien respondía a la pregunta del título ('¿la dirección IP puede ser un componente de la autenticación de 2 factores?'), pero no la parte específica que se refiere a la administración de ssh. Diría que la contraseña está protegida por contraseña ssh la clave es esencialmente una autenticación de dos factores: algo que tienes (la clave ssh) y algo que sabes (la clave de la contraseña).

Técnicamente, sí, pero agregar un segundo factor que es trivial para forjar no aumenta tu seguridad en gran medida.

Suponiendo que se te haya recomendado utilizar el factor 2 porque algún tipo de evaluación de riesgos sugirió que necesitabas una autenticación más sólida, entonces deberías buscar mejores controles.

(Aunque también en la lista blanca de IP, no es muy fuerte, pero solo tomará uno o dos minutos, ¿por qué no?)

La clave es recordar que "factor 2" no es una frase mágica que lo haga seguro. Debe comprender el riesgo e implementar controles adecuadamente sólidos.

Por lo general, la autenticación de 2 factores se refiere a algo que "sabes" y algo que "tienes". El "know" es una contraseña y "have" es ssh keys. Estos podrían usarse de la forma en que los está utilizando ahora o en algún tipo de tarjeta inteligente o dongle (a la que sshd luego accede mediante GSSAPI; consulte man sshd_config ).

Creo que la persona que te pidió que utilices la autenticación de 2 factores quiere que utilices claves y contraseñas (si alguien roba tu clave, no importa porque tampoco conocen la contraseña).

Una dirección IP no es realmente algo que "poseas" porque, como has dicho, puede ser falsificada. Lo mismo con las direcciones MAC. Sin embargo, puede bloquear el acceso sshd a ciertas direcciones IP / rangos de todos modos como un medio para dificultar el hostigamiento del servidor ssh. Por ejemplo, ejecutar sshd en el puerto predeterminado en Internet llevará a muchas personas a intentar forzar contraseñas de fuerza bruta, etc .; la restricción a las direcciones IP debería ayudar con esto, ya que requiere más persistencia y configuración para falsificar la IP. Ponga una línea similar a la siguiente en /etc/hosts.deny

sshd,sshdfwd-X11:ALL

y esto en /etc/hosts.allow

sshd,sshdfwd-X11: 192.168.0.0/255.255.255.240
sshd,sshdfwd-X11: 127.0.0.1

(la dirección IP / máscara de subred anterior define un rango de direcciones; es solo un ejemplo).

Siempre verifique dos veces cuando realice este tipo de modificaciones, ya que no quiere bloquearse accidentalmente de su servidor. Siempre deje una sesión iniciada mientras realiza las pruebas (ya que estos cambios solo afectan a los nuevos inicios de sesión).

¿Son relevantes las semánticas aquí? El hecho de que "se le haya recomendado usar la autenticación de 2 factores" sugiere que alguien espera esto de usted, por lo que no tiene más sentido averiguar por parte de la persona con la expectativa qué se consideraría aceptable.

No. No debe confiar en la dirección IP para proporcionar mucha seguridad. Si alguien se conecta a través de una red inalámbrica abierta (por ejemplo, desde su teléfono inteligente o desde su computadora portátil en una cafetería pública), es trivial montar un ataque de hombre en el medio o falsificar su dirección IP. Para esos usuarios, la dirección IP no agrega ninguna seguridad.

Por lo tanto, si le informaron que debe usar la autenticación de 2 factores, no debe tratar la dirección IP del cliente como un segundo factor. Para algunos de sus usuarios, esto será básicamente inútil.

Yo diría que está bien filtrar las conexiones SSH para permitir solo aquellas desde un rango de direcciones IP limitado. Esto podría aumentar un poco. Sin embargo, ¡no lo consideres como un segundo factor! Si necesita autenticación de dos factores, use dos factores reales. No intentes "tirar uno rápido" con un segundo factor falso.

Permítame contarle una pequeña historia sobre otro segmento de la industria que logró una rápida con autenticación de 2 factores. Hace varios años, los reguladores bancarios de EE. UU. Aprobaron una regulación que exigía a todos los bancos de EE. UU. Que usaran la autenticación de dos factores para la banca en línea. Un requisito plausible, especialmente si le preocupan los ataques de phishing para robar las contraseñas bancarias de las personas. Pero luego los bancos se pusieron "listos" (y no me refiero a eso de buena manera) sobre cómo implementaron el requisito. Decidieron que su contraseña de banca en línea sería el primer factor (hasta ahora bien) y una cookie persistente en su máquina sería el segundo factor (bueno, plausible). Pero, ¿cómo obtuvieron la cookie persistente en su máquina? Bueno, si no tiene la cookie, le hacen su pregunta de seguridad, y si puede proporcionar la respuesta correcta, le dan la cookie. Entonces, al final, sus dos factores son: (1) una contraseña y (2) otra contraseña (la respuesta a su pregunta de seguridad). Esto anula el propósito de la autenticación de dos factores. Por ejemplo, un phisher puede pedir ambas contraseñas. Y de hecho, algunos estudios han encontrado que esta forma de autenticación de dos contraseñas no es más segura contra el phishing que la autenticación de una sola contraseña. Así que no seas como los bancos. No trate la autenticación de 2 factores como algo que puede jugar, porque entonces negará sus beneficios de seguridad.

En cierto sentido, sí. Pero es más una cuestión de semántica que de seguridad.

En cierto sentido, una dirección IP podría considerarse "algo que eres" o "algo que tienes"; es decir, si el acceso está restringido a solo un conjunto limitado de direcciones IP, entonces un atacante tendría que "ser" o "tener" una de esas direcciones IP para perpetrar un ataque: cómo sucedería eso depende del escenario y tecnología, pero sin duda disminuirá drásticamente tu superficie de ataque.

La semántica viene como parte del argumento de si cuenta como un segundo factor, o si es solo una pieza de seguridad adicional realmente buena. Técnicamente no eres tu dirección de IP ni es realmente tuya; alguien más puede asumir el control dependiendo de la estructura de la red. Pero lo mismo ocurre con cualquier otra tecnología de autenticación: todo depende de la implementación.

La única vez que realmente importa si cuenta o no, como segundo factor se encuentra en el contexto de algún tipo de auditoría de proceso o un marco más amplio, en cuyo caso deben enumerarse los factores de calificación. De lo contrario, solo son nerds que discuten.

Diría que exigir una contraseña más imponer una restricción de IP es una seguridad muy razonable, siempre y cuando se sigan estrictamente las políticas apropiadas. Ciertamente es mejor que solo la contraseña sola.

No debes usar la dirección IP como un factor de autenticación. Es fácil falsificar una dirección IP en lugar de descifrar otros medios como la biométrica. Un script para niños puede hacerlo fácilmente.

¿Cómo puedes lidiar con los cambios de dirección IP involuntariamente como usar VPN? Hay muchas soluciones para usar la autenticación de dos factores SSH. Puedes simplemente buscarlos en Google.

La IP sería demasiado fácil de falsificar o incluso de adivinar basada en una subred. Sólo hay tantas opciones allí. No lo consideraría útil. Hay muchos otros sistemas de 2 factores que puede usar que son simples y funcionan. Mira a LinOTP y OpenOTP.

Otra opción es restringir el acceso solo a las máquinas que usan una tarjeta inteligente o que tienen habilitada otra forma de factor 2.

Alguna respuesta práctica que puedes o no puedes creer.

Una vez trabajé para una compañía que hizo un sitio secundario para MasterCard. Eso sí, no fue nada muy relacionado con la seguridad, ni números CC, ni transacciones. Un pequeño concurso con pequeños precios. Pero esto significa que el sitio tenía un mecanismo de inicio de sesión y cierta información personal (inicio de sesión, correo electrónico, tal vez incluso una dirección postal). Los procedimientos de MC exigían alguna forma de 2FA para la gestión de servidores de producción y el filtrado basado en IP, limitado a 1 dirección IP (puerta de enlace desde el edificio) se consideraba suficiente. Por otro lado, el sitio era de tan bajo valor que no se molestaron en verificar realmente lo que dijimos, han tomado nuestra palabra. Pero la idea fue incluir el filtro de IP, ya que 2FA fue su idea, lo pidieron explícitamente, no hemos pensado que incluirlo sea parte de 2FA.