2009-11-24 8 views
5

Suponiendo que tenemos un servidor S y unos pocos clientes (C) y siempre que un cliente actualice un servidor, una base de datos interna en el servidor se actualiza y se replica a los otros clientes. Todo esto se hace usando sockets en un entorno de intranet. Creo que un atacante puede olfatear con bastante facilidad este tráfico de texto sin formato. Mis colegas creen que soy demasiado paranoico porque estamos detrás de un firewall.Client Server socket security

¿Estoy siendo demasiado paranoico? ¿Conoce algún exploit (enlace, por favor) que aprovechó una situación como esta y qué se puede hacer de manera diferente? Los clientes se reescribieron en Java, pero el servidor aún usa C++. Cualquier cosa en el código puede proteger contra un ataque?

Respuesta

3

Sus colegas son na ï ve.

Se produjo un ataque de alto perfil en Heartland Payment Systems, un procesador de tarjeta de crédito que uno esperaría tener extremadamente cuidado con la seguridad. Suponiendo que las comunicaciones internas detrás de su firewall fueran seguras, no usaron algo como SSL para garantizar su privacidad. Los hackers pudieron espiar ese tráfico y extraer datos confidenciales del sistema.

Aquí es another story con un poco más de la descripción del ataque en sí mismo:

Descrito por Baldwin como "bastante sofisticado ataque ," él dice que ha sido un reto para descubrir exactamente cómo sucedió. Los equipos forenses encontraron que los piratas informáticos "estaban tomando números con malware sniffer como pasó por nuestra plataforma de procesamiento," Baldwin dice. "Desafortunadamente, somos seguros de que los nombres de los titulares de tarjetas y los números estuvieron expuestos". Los datos, incluyendo las transacciones con tarjetas enviados a través de plataforma interna de procesamiento de Heartland, se envía sin cifrar, que explica, "A medida que la transacción está siendo procesado, que tiene que estar en forma no cifrada para obtener la solicitud de autorización a cabo."

+0

Gracias por el enlace y su tiempo. – ritu

1

Puede hacer muchas cosas para evitar que un hombre en el medio ataque. Para la mayoría de los datos internos, dentro de una red protegida con firewall/IDS, realmente no necesita protegerla. Sin embargo, si desea proteger los datos que puede hacer lo siguiente: cifrado

  1. Uso de PGP para firmar y cifrar mensajes
  2. cifrar los mensajes sensibles
  3. funciones
  4. uso de hash para verificar que el mensaje enviado no tiene sido modificado

Es un buen procedimiento de operación estándar para proteger todos los datos, sin embargo, la seguridad de los datos tiene un costo muy elevado. Con canales seguros, debe tener una autoridad de certificación y permitir un procesamiento adicional en todas las máquinas que participan en la comunicación.

5

Dentro del firewall de su empresa, está bastante a salvo de los ataques directos desde el exterior. Sin embargo, las estadísticas que no tendré problemas para desenterrar afirman que la mayor parte del daño a los datos de una empresa se realiza desde INside. La mayoría de eso es un simple accidente, pero hay varias razones por las cuales los empleados se descontentan y no se enteran; y si sus datos son sensibles, podrían dañar a su compañía de esta manera.

También hay montones de leyes sobre cómo manejar los datos de identificación personal. Si la información que está procesando es de ese tipo, tratarla sin cuidado dentro de su empresa también podría abrir su empresa a litigios.

La solución es usar conexiones SSL. Desea utilizar una biblioteca preempaquetada para esto. Proporciona claves privadas/públicas para ambos extremos y mantiene las claves privadas bien ocultas con los privilegios habituales de acceso a archivos, y el problema de la inhalación casi siempre se soluciona.

+1

Eso es lo que recomendé, usando SSL. – ritu

+0

Todo lo que necesita es una computadora infectada dentro de su red para crear un vector para que entren los ataques desde el exterior (independientemente de si hay un firewall o no) porque una computadora infectada puede configurarse para usarse como un proxy para ejecutar comandos específicos que son solicitudes recibidas a través de un protocolo comúnmente aceptado (HTTP) y ejecutarlas localmente. Para datos como el correo electrónico (a menos que esté usando gmail que usa HTTPS de forma predeterminada), sus mensajes se envían a través de la red en texto sin formato. Es posible interceptarlos y leerlos directamente con una herramienta bien escrita. –

+0

Si se encuentra en una red que usa conmutadores en lugar de concentradores, se hace más difícil olfatear todo el tráfico en la red, pero todavía hay formas de evitarlo. Al enviar solicitudes de actualización de ARP falsificadas, puede piratear la red para hacer creer que todos los paquetes deben pasarse a un host (que a su vez los reenvía a la puerta de enlace 'real'. Esto se conoce como ataque de hombre en el medio) Afortunadamente, existen herramientas que detectan actividad ARP sospechosa y es muy fácil detectar actividad como esta si alguien está prestando atención. –

3

SSL proporciona cifrado y autenticación. Java lo tiene built in y OpenSSL es una biblioteca de uso común para C/C++.

0

Casi todas las aplicaciones "importantes" que he usado se basan en SSL u otra metodología de cifrado.

El hecho de que esté en la intranet no significa que no tenga código malicioso ejecutándose en algún servidor o cliente que pueda estar intentando olfatear el tráfico.

1

Estás siendo paranoico. Está hablando de datos que se mueven a través de una red interna segura e ideal.

¿Se puede olfatear la información? Sí, puede. Pero es olfateado por alguien que ya ha violado la seguridad de la red y se metió dentro del firewall. Eso se puede hacer de innumerables maneras.

Básicamente, para la mayoría de las empresas VAST, no hay razón para cifrar el tráfico interno. Casi siempre hay maneras mucho más sencillas de obtener información, desde el interior de la empresa, sin siquiera acercarse a "olfatear" la red. La mayoría de estos "ataques" provienen de personas que simplemente están autorizadas para ver los datos desde el principio y que ya tienen una credencial.

La solución no es encriptar todo su tráfico, la solución es monitorear y limitar el acceso, de modo que si hay datos comprometidos, es más fácil detectar quién lo hizo y a qué tenían acceso.

Finalmente, considere que los administradores del sistema y los DBA prácticamente tienen carta blanca para todo el sistema de todos modos, ya que inevitablemente, alguien siempre necesita tener ese tipo de acceso. Simplemente no es práctico encriptar todo para mantenerlo alejado de miradas indiscretas.

Finalmente, estás haciendo un gran ruido sobre algo que es igual de probable escrito en un adhesivo adherido en la parte inferior del monitor de alguien de todos modos.

+0

Ver comentarios de patros. – ritu

0

Un atacante que tiene acceso a un dispositivo dentro de su red que le ofrece la posibilidad de olfatear todo el tráfico o el tráfico entre un cliente y un servidor es el mínimo requerido.
De todos modos, si el atacante ya está adentro, olfatear debe ser solo uno de los problemas que tendrá que tener en cuenta.

No conozco muchas empresas que usen conectores seguros entre clientes y servidores dentro de una intranet, principalmente debido a los mayores costos y el menor rendimiento.

1

¿Tiene contraseñas en sus bases de datos? Ciertamente espero que la respuesta sea sí. Nadie creería que la contraseña para proteger una base de datos es demasiado paranoica. ¿Por qué no tendría al menos el mismo nivel de seguridad * en los mismos datos que fluyen a través de su red? Al igual que una base de datos no protegida, el flujo de datos no protegidos a través de la red es vulnerable no solo al rastreo, sino también a un atacante malintencionado. Así es como encuadraría la discusión.

* Con el mismo nivel de seguridad me refiero a usar SSL como algunos han sugerido, o simplemente cifrar los datos usando una de las muchas bibliotecas de cifrado disponibles si debe usar sockets sin formato.