Previniendo al hombre en el ataque central (LAN)

3

Estoy trabajando en una aplicación de chat de área local que simplemente establecería la conexión entre dos sockets en la LAN y continuaría con la comunicación. Ahora, centrado en la seguridad, mi principal preocupación es evitar que mi aplicación se filtre debido a un ataque mitm exitoso.

  • En la web hay verificación de certificados, pero no tengo ningún servidor dedicado, ya que puede ser simplemente una comunicación entre los dos únicos nodos de la red.
  • La pregunta más cercana fue esta: Preventing man in the middle ataque , pero agregar una entrada estática en la tabla ARP no es viable ni viable en mi caso.
pregunta Kaustubh 06.01.2016 - 20:33
fuente

2 respuestas

2

No puede crear una aplicación de manera que no sea vulnerable a los ataques de MiTM porque estos ataques ocurren en una capa más baja de la que funciona su aplicación. Solo puede proteger la red que utilizan los clientes. Hay varias contramedidas disponibles. Primero necesita seguridad de puerto que evitará muchos de estos ataques. Luego, puede agregar un IDS / IPS basado en la red que captura el puerto del monitor de su conmutador. Pero todo esto no vendrá gratis, te costará algo de dinero y mucho tiempo.

// La solución más práctica es usar el cifrado para garantizar que alguien que realiza un ataque MiTM no pueda leer los datos que captura. Pero incluso esto no te dará 100% de seguridad. El principal problema aquí es que no tienes un servidor.

Inscripción asíncrona (como SSH)

En ambos lados, creas un par de claves RSA y luego lo usas para cifrar y descifrar mensajes. Cuando se establece la primera conexión entre dos hosts, guarda la clave de ese host para identificarlo en sesiones posteriores. El problema aquí es que un MiTM-Attacker podría interrumpir la primera sesión. Luego se encuentra en una posición en la que puede inyectar sus propios certificados para realizar un ataque MiTM de todos modos. Esto también conducirá a una situación en la que, en sesiones posteriores que no son interrumpidas por el atacante, la conexión se reconocerá como insegura porque la clave guardada del host de inicio es, de hecho, la del atacante.

Su problema es que no conoce la clave del lado de impresión hasta que se conecta por primera vez. Muchas empresas resuelven este problema cuando se trata de ssh sincronizando el ssh_known_hosts a través de un servidor confiable. No tiene este servidor debido a que no puede hacer esto aquí y se siente inseguro en la primera conexión.

Pree-Shared-Key

Puede implementar el cifrado con una clave previamente compartida, pero el problema aquí es siempre la capacidad de uso y el comportamiento del usuario. Cuando genera un PSK para cada conexión, entonces la clave debe ser intercambiada. Siempre recuerda: la gente es perezosa. Enviarán el PSK a través del correo, que posiblemente no esté encriptado. Además, muchas personas podrían decir "ohh, eso es complejo. Usaré otro software que sea fácil de usar" y así es como las personas terminan con un software fácil de usar pero totalmente inseguro.

// Además, ninguno de los procedimientos descritos impedirá que un MiTM-Attack solo evite que el ataque tenga éxito en la forma en que estaba previsto.

    
respondido por el davidb 06.01.2016 - 20:48
fuente
0

Solo para agregar a la respuesta de @davidb, solo necesita una clave simétrica preestablecida para realizar la comunicación encriptada, que debería ser lo suficientemente simple. Si esto no funciona, puede usar certificados firmados por su propia CA que tanto el cliente como el servidor conocen, y facilitar la comunicación segura.

    
respondido por el sandyp 07.01.2016 - 00:16
fuente

Lea otras preguntas en las etiquetas