Inicio > Mis eListas > infohackers > Mensajes

 Índice de Mensajes 
 Mensajes 141 al 155 
AsuntoAutor
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
 << 20 ant. | -- ---- >>
 
Infohackers.org
Página principal    Mensajes | Enviar Mensaje | Ficheros | Datos | Encuestas | Eventos | Mis Preferencias

Mostrando mensaje 226     < Anterior | Siguiente >
Responder a este mensaje
Asunto:[boletín_informativos] informativos.info #214
Fecha:Domingo, 26 de Febrero, 2006  18:20:08 (+0100)
Autor:Infohackers <infohackers @...........org>

informativos.info

 

Editado por AIH: www.infohackers.org

Boletín informativos.info

5.800 subscriptores

Boletín número 214

Hacktivismo y seguridad

26 de Febrero de 2006


Sumario
 

Opinión: El eslabón más débil
 


Hace unos meses, dentro de la serie de artículos sobre seguridad en capas, comentaba que, muchas veces, el eslabón más débil de la cadena de seguridad era el usuario. La experiencia dicta que la forma más fácil de entrar en un sistema no es, la mayor parte de las veces, un desbordamiento de buffer o una inyección de código SQL, sino convencer a un usuario que realice una acción contraria, no ya sólo a las políticas de seguridad de la empresa, sino al sentido común.

Esta semana se conocían los resultados de un experimento que realizó una empresa británica dedicada a la formación en seguridad en Londres. La tarea fue muy sencilla. En la calle, unos empleados de la empresa repartían a los transeúntes (empleados en la mayor parte de las empresas de los alrededores, bancos y compañías de seguros) un CD promocional. Este CD contenía advertencias en la portada sobre la necesidad de desconfiar de software obtenido de sitios no confiables (y una persona repartiendo por la calle, desde luego, no lo es) y sobre la posible vulneración de las políticas de seguridad de las empresas al ejecutar software no aprobado.

Como era de esperar, la curiosidad pudo más que la lógica y muchos empleados introdujeron el CD, curiosearon y ejecutaron programas dentro de los ordenadores de la empresa. La compañía que realizó la campaña no da datos concretos, pero a cualquiera no se le escapa que, seguramente, el porcentaje ha sido escandaloso. Se puede leer más sobre este hecho en Hispasec.

¿Existe una solución a estos problemas? Solución final y radical, no. Pero existen varias medidas paliativas. La medida más clásica en este terreno suele ser de tipo coercitivo. Se fija una política de empresa clara sobre el uso permitido de los sistemas informáticos y se establecen castigos contra su incumplimiento. Si metes software no autorizado, estás en la calle. Sin embargo, como en todos los modelos de castigo, el daño ya está hecho. Probablemente sea un buen ejemplo para que el próximo empleado se lo piense antes de meter el "CD promocional", pero, mientras tanto, nos enfrentamos a la ardua tarea de eliminar ese troyano de la red, a la pérdida de datos o, lo que es peor, a que nuestra competencia se haga con nuestras bases de datos, nuestros proyectos empresariales y los planos del nuevo producto que tenemos pensado sacar.

Las medidas a nivel de sistema, aunque más complicadas de instaurar, pueden ser más efectivas. Hace poco, en una de las listas de correo en las que participo, surgió el tema. Un administrador de una red, concretamente bajo Windows, quería limitar los programas que sus usuarios podían ejecutar. Surgieron varias propuestas, pero una me llamó la atención. En vez de prohibir ejecutar programas, se crea una lista blanca de los programas que se pueden ejecutar. Es decir, si en nuestra empresa usamos, por ejemplo, OpenOffice, Firefox, Thunderbird y un programa de gestión, los usuarios solo pueden ejecutar esos programas. Existen soluciones para limitar la capacidad del sistema para ejecutar otros programas, incluso basándose en hashes de los ejecutables.

No es una solución perfecta. Por ejemplo, si usamos Word, todavía somos vulnerables a los virus de macro. Si permitimos el acceso a la web, es posible que un troyano aproveche alguna vulnerabilidad del sistema o del explorador. Pero hemos limitado en gran parte los problemas de usuarios ejecutando software no autorizado.

De todas formas, estas soluciones siempre tienen que estar complementadas (o ser, en realidad, un complemento a) por la medida más eficaz: la formación del usuario. Si el usuario tiene claro cuales son las implicaciones de acceder a software peligroso, probablemente no intente siquiera llevárselo a la empresa. Las medidas limitadoras son una barrera final. Es el mismo usuario el primero que debe ser consciente de su papel en la seguridad.

Luisma
Miembro de la AIH
Licencia de Creative Commons
Esta obra está bajo una licencia de Creative Commons.

   

Introducción a las redes TCP-IP: El protocolo ARP
 


Hemos visto como, en la capa 3 y usando el protocolo IPv4, los dispositivos de red tienen una dirección IP. También en la capa 2, sobre Ethernet, los dispositivos tienen una dirección MAC. ¿Como se relacionan estas dos direcciones? Es decir, si desde la capa 3 quiero acceder a otra dirección IP de la capa 3, ¿como se sabe la dirección MAC de la capa 2 que ha de recibir el datagrama?

Para ello se emplea (siempre hablando de IPv4 sobre Ethernet) el protocolo ARP. ARP son las siglas de Address Resolution Protocol o protocolo de resolución de direcciones. La función de este protocolo es formar parte del interface entre los niveles OSI de red y de enlace de datos y relacionar cada dirección IP con la dirección MAC que debe recibir el paquete. Ojo, no es necesariamente la misma dirección IP destino del paquete de nivel 3 la que recibirá, a nivel de capa 2, el paquete de nivel 2 que contenga este paquete de nivel 3. Si la dirección IP de destino está dentro de nuestra subred, será así. Pero si el destino es fuera de la red, el protocolo IPv4 deberá enviarlo al router que tenga definido en su tabla de rutado.

Para averiguar la dirección MAC del destino, se usan cuatro tipos de paquetes ARP:

  • ARP request

  • ARP reply

  • RARP request

  • RARP reply

El proceso es como sigue:

El equipo A quiere enviar un paquete al equipo B, del que sabe su IP, pero desconoce su dirección MAC. Lo primero que hace es enviar un paquete ARP request a la dirección MAC Broadcast para que lo reciban todos los equipos de la subred. En el interroga a la red preguntando cual es el equipo que tiene la IP buscada. Al ser un paquete broadcast, todos los equipos de la subred recibirán el paquete, pero solo el que tenga esa IP responderá con un ARP reply indicando cual es su MAC. Este resultado queda almacenado en la tabla ARP del equipo interrogante, de manera que la próxima vez que tenga que enviar un paquete a esa IP, ya usará la MAC de la tabla. Los paquetes RARP sirven para hacer la resolución inversa, de MAC a IP.

Cuando en el centro de la red existe un dispositivo inteligente de nivel 2 (switch), este equipo se encarga de almacenar su tabla ARP, de manera que cuando un equipo emite un ARP request y el switch lo tiene en su tabla, ya responde sin necesidad de propagar un broadcast a toda la red.

El protocolo ARP desaparecerá con IPv6. Presenta varios fallos de diseño y es sensible a ataques de envenenamiento ARP, a los cuales dedicamos un artículo en el boletín 166.

Luisma
Miembro de la AIH
Licencia de Creative Commons
Esta obra está bajo una licencia de Creative Commons.

   

Resumen de noticias de la semana
 


Desbordamiento de buffer en Winamp

Un nuevo fallo se ha descubierto en Winamp, concretamente en el tratamiento de las listas de reproducción m3u, que provoca un desbordamiento en un buffer.


Dos fallos en PostgreSQL

Se han descubierto dos fallos en el conocido servidor SQL PostgreSQL que pueden llevar a una denegación de servicio y a una escalada de privilegios.


Grave fallo en Safari

Un fallo en Safari, el navegador incluido con el MacOS X, se une a la serie de publicación de malware durante la semana pasada para el sistema de Apple. Sin embargo, este fallo es más grave, ya que no precisa de interacción por parte del usuario.

 


El correo del lector
 


Esta sección esta dedicada a resolver vuestras dudas y recibir vuestros comentarios sobre los artículos de este boletín y sobre temas de seguridad informática. Os animamos a escribirnos a el_lector@infohackers.net.

Recibimos con frecuencia peticiones para acceder a boletines antiguos. Os recordamos que están todos en www.informativos.info y que los estamos poniendo en pdf en nuestra web www.infohackers.org.
 

  Hemos recibido varios correos sobre el formato del boletín, en muy diversos sentidos. Os invitamos a votar en la encuesta que está disponible en nuestra página web www.infohackers.org para saber vuestra opinión. Gracias por colaborar.

Las opiniones vertidas pertenecen a sus autores y la AIH no se identifica necesariamente con ellas.
Los derechos de los artículos pertenecen al autor. Para reproducirlos, es necesario ponerse en contacto con el mismo. Desde la AIH animamos al uso de licencias libres tipo CreativeCommons, pero es decisión personal de cada autor el tipo de licencia que use.
La maquetación, logotipos y nombre son propiedad de la Asociación para la Información de Hackers. Todos los derechos reservados..
Los nombres de productos y marcas registrados son propiedad de sus respectivos dueños.


Para envío de noticias: informativos@infohackers.net.
Para envío de sugerencias y preguntas: el_lector@infohackers.net

Desarrollado por la A.l.H. - www.infohackers.org
Para darte de baja, envía un correo a la dirección: infohackers-baja@eListas.net
Para darte de alta, envía un correo a la dirección: infohackers-alta@eListas.net
Los números anteriores de este boletín se pueden consultar en elistas.net.
La base de datos de suscriptores es creada y mantenida por elistas.net.
Toda consulta, cancelación de datos y demás derechos recogidos en la ley deben de ser ejercidos frente a elistas.net

 



[Adjunto no mostrado: 6/ (application/octet-stream) ]
[Adjunto no mostrado: 5/ (application/octet-stream) ]
[Adjunto no mostrado: 3/ (application/octet-stream) ]

[Adjunto no mostrado: 2/ (application/octet-stream) ]
[Adjunto no mostrado: 1/ (application/octet-stream) ]