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 230     < Anterior | Siguiente >
Responder a este mensaje
Asunto:[boletín_informativos] informativos.info #218
Fecha:Domingo, 16 de Abril, 2006  22:43:29 (+0200)
Autor:Infohackers <infohackers @...........org>

informativos.info

 

Editado por AIH: www.infohackers.org

Boletín informativos.info

5.910 subscriptores

Boletín número 218

Hacktivismo y seguridad

16 de Abril de 2006


Sumario
 

Editorial: Cambios en el boletín
 


He aquí el primer boletín con la nueva periodicidad mensual. Hemos recibido bastantes correos apoyando este cambio, así que esperamos que sea de vuestro gusto. Nos gustaría oír vuestros comentarios y opiniones, tanto favorables como críticas. Ayudadnos a mejorar y hacer este boletín cada vez más vuestro.

El equipo de Informativos.info

   

Opinión: Tus derechos o los míos
 


A principios del pasado mes de Noviembre, tuve la suerte de que mi novia (espero que esta palabra sea acertada y no tenga consecuencias) viniese a pasar unos días conmigo. Como es natural, no pude resistirme a sus encantos y le regale unos cuantos CD que posteriormente convertí a MP3 y traspase a su reproductor MP3 portátil. Ya se sabe, “para no aburrirme en el viaje”.

Esto no tendría la mayor trascendencia ni seguramente es del interés de todos vosotros (y posiblemente seguirá sin serlo), pero uno de esos CD resulto ser de Sony-MGM. Sí. De los que incorporan regalo sorpresa en formato rootkit.

No voy a relataros toda la historia ni los daños que eso me supuso. Los daños podéis imaginarlos, y la historia queda bastante clara aquí.

La semana pasada leo que otra poderosa discográfica, EMI, vuelve a instalar “cositas” en nuestros ordenadores. Eso si esta vez pide permiso. Si se lo das se instala, sino, también.

Bueno, y después de haberme extendido casi en demasía, a lo que iba desde el principio, los derechos:

El derecho a que un autor cobre por su trabajo.
El derecho de una discográfica a proteger su inversión.
El derecho de una tienda a vender discos.
Y (los mas importantes para mi) mi derecho a la intimidad, a saber que software esta funcionando en mis ordenadores, que la información que contienen esta segura….

Creerme si os digo que los derechos de los tres primeros han quedado ampliamente satisfechos con la compra del original en una tienda y no han sido dañados por el hecho de copiar a un reproductor MP3 propiedad del titular del original. En cuanto a los míos, los más importantes para mi, se los han pasado por el arco del triunfo. Como dicen por el ciberespacio, están consiguiendo que el que no les odia empiece a hacerlo.

Espero que dejen esta política de criminalizar y usarnos como basura, carne de cañón que solo sirve de combustible para su maquinaria de amasar dinero. Al fin y al cabo somos sus clientes, los que les damos de comer y finalmente los que podemos dejarles de lado.
 

Iridium
Miembro de AIH

Licencia de Creative Commons
Esta obra está bajo una licencia de Creative Commons.

   

Opinión: Virtualización, la tendencia actual
 


En estos días se está hablando mucho de virtualización. Esta tendencia se había venido elevando desde hace unos meses, pero con la salida de aplicaciones gratuitas por parte de sus principales actores, primero VMware con VMware Player y la beta de VMware Server, y el anuncio de Microsoft de que Virtual Server 2005 R2 será gratuito y dará soporte a Linux, ha disparado la aceptación de esta tecnología.

La virtualización consiste en crear un entorno, una máquina virtual (valga la redundancia), corriendo dentro de un sistema operativo. En esta máquina se puede instalar otro sistema operativo, que será totalmente independiente del sistema anfitrión, y que accederá al hardware que se determine en el software de virtualización. De esta forma, sobre el mismo hardware podemos correr dos o más sistemas distintos e independientes. Evidentemente, el rendimiento de un sistema sobre una máquina virtual nunca va a ser comparable con el de un sistema corriendo nativamente sobre el hardware, especialmente cuando se trata del subsistema gráfico, pero si tiene interesantes aplicaciones.

La primera utilidad que se le dio a la virtualización fueron los entornos de pruebas. Si deseamos crear laboratorios donde poder probar aplicaciones o configuraciones nuevas, para talleres, aprendizaje, o para comprobar si el sistema funcionará correctamente, esta es una solución ideal. Una máquina con bastante RAM y disco duro puede ser suficiente para simular un sistema relativamente complejo, sin riesgo. Además, las aplicaciones de virtualización suelen llevar una característica conocida como snapshot que permite retornar el sistema virtual a un punto conocido, deshaciendo los cambios que se hubiesen realizado durante una sesión.

El siguiente campo donde se empezó a aplicar esta tecnología fue el de las demostraciones técnicas. Si habéis acudido últimamente a alguna charla técnica de Microsoft, visteis que el ponente, con un simple portátil, presenta características complejas, como simular varias sedes conectadas por distintas redes o árboles de dominios con múltiples controladores. En este campo, la ventaja de la virtualización es innegable.

Sin embargo, en el último año se ha venido hablando mucho de una palabra: consolidación. Los servidores se hacen cada vez más potentes y, en muchos casos, están infrautilizados. Sigue siendo necesario tener una gran cantidad de ellos, por razones de redundancia, separación de funciones, seguridad y otras muchas. Entonces, ¿por qué no usar la virtualización para conseguir que un solo equipo sea, de cara a la red, varios sistemas? De esta forma se consigue un importante ahorro en el coste del hardware y en los servicios que lleva asociado, como espacio, aire acondicionado, consumo eléctrico y mantenimiento, en los cada vez más poblados centros de proceso de datos. Es por ello que muchas empresas ya están apostando por esta tecnología y reduciendo sus racks en favor de menos servidores, pero más aprovechados.

Fuera de la empresa, para el aficionado a la seguridad informática y las redes, la virtualización es una bendición del cielo. En estos días de RAM y disco duro baratos, el montarse un escenario complejo donde probar distintos sistemas, configurar redes segmentadas o realizar pruebas de penetración contra varios equipos en cascada, está al alcance de cualquiera. Personalmente, llevo probando los sistemas de virtualización desde hace bastantes años para este tipo de cosas, pero hasta que la RAM se puso a un precio razonable no era práctico tener más de una o dos máquinas virtuales arrancadas a la vez. Hoy, con los fabricantes ofreciendo gratuitamente versiones reducidas y los equipos nuevos trayendo de serie 1 Gb de RAM como mínimo, montar un escenario con tres o cuatro sistemas está al alcance de la mayoría. Y ampliar este número es, básicamente, cuestión de añadir DIMM de memoria a nuestro ordenador.

Os invito a que probéis esta tecnología. Un buen punto para empezar es la web de VMware. Allí tenéis disponible para descarga el VMware Player y varias máquinas virtuales ya configuradas con sistemas de código abierto. También, si buscáis algo más complejo y potente, os recomiendo que desde el mismo sitio os descarguéis la beta de VMware Server (también gratuita). Seguro que le encontráis utilidad.

Luisma
Miembro de AIH

Licencia de Creative Commons
Esta obra está bajo una licencia de Creative Commons.

   

Introducción a las redes TCP/IP: Capa 3 - Enrutamiento (I)
 


Hasta ahora hemos visto como se comporta el protocolo IP en una zona local. Sin embargo, la característica esencial de la capa 3 es que permite la interconexión de redes locales, estableciendo caminos entre ellas para permitir que los paquetes lleguen a su destino independientemente de la distancia. Vamos a ver en detalle como funciona este proceso.t>

Tabla de ruta

El mecanismo básico que usa IP para determinar como llegar a otras redes son las tablas de rutado. Estas tablas contienen las rutas para llegar a las distintas redes, es decir, como y por donde están accesibles los distintos rangos de IP. En general, tienen la siguiente estructura:

IPdestino         Máscara          Puerta de enlace          Interface          Métrica

La IP de destino y la máscara definen un rango de IP. La puerta de enlace indica que todos los paquetes destinados a esa IP deben de ser enviados a la dirección MAC que corresponde a la misma. El interface define cual es usado para el envío y la métrica define un “peso” o “coste”, es decir, la preferencia de usar esa puerta de enlace con respecto a otras que pudieran tener también una ruta definida. Por ejemplo, tomemos esta ruta:

192.168.1.0     255.255.255.0            192.168.2.100            192.168.2.110            10

En este caso, cuando desde nuestro equipo se desee enviar un paquete a un host comprendido dentro del rango 192.168.1.0/255.255.255.0, debe de ser enviado al host que responde a la IP 192.168.2.100  a través del interface local que tiene la IP 192.168.2.110 (depende del sistema, también puede ser referenciado con el nombre del dispositivo, p. e. eth0). La ruta tiene una métrica de 10, lo que quiere decir que tendrá preferencia sobre una que tenga una métrica de 20 pero no sobre una que tenga una métrica de 1.

Un caso particular es el denominado Default Gateway o puerta de enlace por defecto. Esta ruta suele estar definida de esta forma:

0.0.0.0             0.0.0.0             192.168.2.1     192.168.2.110            20

La red  0.0.0.0/0.0.0.0 indica cualquier IP. La puerta de enlace sería, en este caso, 192.168.2.1, a través del interface 192.168.2.110, con una métrica de 20. Si en una tabla de rutado tuviésemos las dos líneas anteriores, los paquetes destinados a la red 192.168.1.0/255.255.255.0 irían a través del host 192.168.2.100, mientras que el resto irán a través del 192.168.2.1. Los paquetes para 192.168.1.0/255.255.255.0 pueden ir a cualquiera de las dos puertas de enlace, pero dado que la métrica es menor en la 192.168.2.100 preferirán esta salida a la 192.168.2.1 siempre que esté disponible.

En una tabla de rutado típica de un host, aparte de las rutas por defecto y a redes concretas, se incluyen también una serie de rutas a los interfaces locales. Así, una tabla de rutado de una estación de trabajo típica podría ser esta:

0.0.0.0

0.0.0.0

192.168.2.1

192.168.2.101

20

127.0.0.0

255.0.0.0

127.0.0.1

127.0.0.1

1

192.168.1.0

255.255.255.0

192.168.2.100

192.168.2.101

10

192.168.2.0

255.255.255.0

192.168.2.101

192.168.2.101

10

192.168.2.101

255.255.255.255

127.0.0.1

127.0.0.1

1

192.168.2.255

255.255.255.255

192.168.2.101

192.168.2.101

1

224.0.0.0

224.0.0.0

192.168.2.101

192.168.2.10

1

255.255.255.255

255.255.255.255

192.168.2.101

192.168.2.101

1

En ella vemos que, aparte de las dos rutas ya comentadas, tenemos una ruta a la red “loopback” a través del interface 127.0.0.1, otra a la red multicast 224.0.0.0 a través del interface local 192.168.2.101, una ruta a la red local 192.168.2.0/255.255.255.0 a través del propio interface local y otras dos a los broadcast 192.168.2.255 y 255.255.255.255 a través de este mismo interface. Estas rutas son creadas automáticamente al arrancar los interfaces, por lo que, en principio, no deberemos de preocuparnos de ellas.

El uso de la métrica nos permite una característica típica de las redes IP: la redundancia de conexiones. Si queremos establecer una conexión fiable entre dos redes, podemos definir dos interfaces, p. e. 192.168.2.1 y 192.168.2.2, y darle dos métricas distintas en función del “coste” (que puede ser el coste monetario o la lentitud del interface, por ejemplo usando en uno una ADSL y en otro una línea dial-up). De estas forma, por defecto los paquetes se conectarán a través de la puerta de enlace que tenga la métrica menor, pero si esta falla, automáticamente tomarán la segunda ruta.

Routers

Un router es un dispositivo o máquina que permite la interconexión entre dos redes distintas. Puede ser dedicado o no. Una característica típica es que tiene, al menos, dos interfaces lógicos (normalmente, asociados a dos interfaces físicos).

Un router recibe paquetes de una red y si van encaminados a la otra, las envía directamente al host de destino. Si van encaminados a otra red, usa la tabla de rutado para determinar cual es la dirección a la que tiene que reenviarlo.

Veamos un ejemplo para detallarlo:

Las tablas de rutado (resumidas) serían:

ROUTER1

192.168.3.0   255.255.255.0    192.168.3.1   192.168.3.1   10
192.168.1.0   255.255.255.0    192.168.1.3   192.168.1.3   10
192.168.2.0   255.255.255.0    192.168.1.1   192.168.1.3   10

ROUTER2

192.168.2.0   255.255.255.0    192.168.2.1   192.168.2.1   10
192.168.1.0   255.255.255.0    192.168.1.1   192.168.1.1   10
192.168.3.0   255.255.255.0    192.168.1.3   192.168.1.1   10

Es decir, las rutas hacia las redes a las que están directamente conectados los routers apuntan a los interfaces correspondientes; y las que van hacia otras redes, apuntan al siguiente router.

En los equipos de las redes 192.168.2.0 255.255.255.0 y 192.168.3.0 255.255.255.0, los gateways o puertas de enlace predeterminados serían los routers respectivos. En la 192.168.1.0 255.255.255.0, hay dos opciones: la más efectiva y complicada es poner rutas estáticas a cada una de las redes; y la más sencilla es poner como gateway predeterminado cualquiera de los routers y este se encargará de redirigir el paquete a la red correspondiente, aun a costa de una carga de trabajo y red mayor.

En este caso, si un paquete saliese del equipo 192.168.3.2 con destino a 192.168.1.2, al no pertenecer a la red propia, iría al router1. Este comprobaría sus tablas de rutado y vería que tiene que sacarlo por el interface 192.168.1.3, que va a la red 192.168.1.0 255.255.255.0.

Si el paquete tuviese como destino 192.168.2.2, iría igualmente al router1, que lo reenviaría al router2 teniendo en cuenta la tercera línea de su tabla de rutado. Este lo recibiría, consultaría su tabla y lo reenviaría a la red  192.168.2.0 255.255.255.0 a través de su interface 192.168.2.1.

Luisma
Miembro de AIH

Licencia de Creative Commons
Esta obra está bajo una licencia de Creative Commons.

   

El sudo de MacOS X frente a root: La verdadera historia
 


En MacOS X, la cuenta de root está desactivada por defecto. La primera cuenta de usuario creada se añade al grupo admin y ese usuario puede usar el comando sudo para ejecutar otros comandos como root. La idea convencional es que sudo es la forma más segura de ejecutar comandos como root, pero una mirada más detallada desvela un cuadro no tan claro.

Que se consigue con sudo

Que es lo que realmente se gana usando sudo en la configuración por defecto del MacOS X? Lo primero, se gana cierta confianza en que nadie puede hacer login como root, tanto localmente como via SSH o FTP, y apropiarse de tu máquina. Lo segundo, se consigue una entrada en /var/log/system.log cada vez que se usa sudo, indicando quien y que comando se ejecutó. Estas parecen razones lo suficientemente buenas para superar la molestia de usar sudo.

Sin embargo, dada la forma en la que sudo está configurado por defecto, solo se necesita la propia contraseña para la autenticación. Esto significa que si alguien roba o adivina tu contraseña y tiene acceso local o vía SSH, puede tomar control de tu máquina exactamente igual que si tuviese la cuenta de root activada.

Lo que es peor, si se ejecuta sudo -s para arrancar una shell de root, la única cosa que queda reflejada en el system.log es:

Mar 20 07:49:12 my-mac-mini sudo: username : TTY=ttyp3 ; PWD=/Users/
username ; USER=root ; COMMAND=/bin/bash

El resto de comandos ejecutados desde esta shell de root no queda registrada en absoluto. Todo lo que podrás decir es cuando alguien arrancó una shell de root. Lo que sucedió después, es un misterio. El mismo problema existe si se ejecuta un programa que permite salidas al shell, como muchos editores de texto, clientes de telnet, etc. Por lo tanto, en realidad, el uso de sudo no nos ha dado ningún beneficio en absoluto sobre la alternativa de activar y usar la cuenta de root.

Estas deficiencias pueden ser mitigadas, y volveremos sobre ello más adelante.

Asegurando la cuenta de root

Si activas la cuenta de root, hay un par de precauciones que deberías tomar. La primera, usa una contraseña distinta de la contraseña de usuario.

Se pueden prevenir los accesos de root a través de SSH cambiando esta línea en el archivo de configuración de sshd, /private/etc/sshd_config:

#PermitRootLogin yes

a esta:

PermitRootLogin no

Una vez hecho, se reinicia el demonio SSH en Preferencias del sistema – Compartir. Si se quiere ir un poco más allá, se puede desactivar todos los accesos mediante contraseña a SSH y permitir solamente autenticación de clave pública. Es así como suelo configurar mis servidores Linux. Hay bastantes recursos en la red que describen todos los detalles de usar autenticación de clave pública en SSH. http://sial.org/howto/openssh/publickey-auth/

Los accesos al FTP como root están desactivados por defecto, toda vez que la cuenta de root está listada en el archivo /etc/ftpusers. Los usuarios incluidos en este archivo no pueden acceder al FTP.

Finalmente, desactiva el acceso de usuarios a sudo comentando la línea %admin en el archivo /private/etc/sudoers:

#%admin ALL=(ALL) ALL

Con este par de cambios menores en la configuración, tenemos un sistema que es posiblemente más seguro que el sistema por defecto usando sudo. ¿Por qué? Pues porque si alguien adivinase nuestra clave de usuario, no podría tener acceso a sudo para tomar control de nuestra máquina. Tendría todavía que conseguir la clave de root. Por supuesto, si tiene una cuenta local, podría intentar un ataque contra una vulnerabilidad de escalada de privilegios, pero ese es un problema que corresponde a Apple solucionar.

De vuelta a sudo

¿Existe alguna manera de hacer la configuración de sudo más segura? Hay muchas cosas que se pueden hacer para mejorar los ajustes por defecto. Aquí van un par de ellas.

El cambio más obvio es requerir una contraseña diferente que la de usuario para autenticarse. Esto se puede hacer mientras se mantiene deshabilitado el acceso como root con un pequeño truco. Primero, activa la cuenta de root y cambia la contraseña. Luego, usando el Gestor de Netinfo para cambiar la shell de root a /usr/bin/false. De esta forma, cualquier intento de abrir sesión como root terminaría instantáneamente. Luego, se puede forzar a sudo para que pida la contraseña de root añadiendo está línea a /private/etc/sudoers:

Defaults:ALL rootpw

Otra mejora de seguridad es configurar las restricciones por usuario y listar los comandos específicos que pueden ser ejecutados usando sudo. Limitando estos comandos, se limita el daño que puede causar un atacante usando una cuenta de usuario. Esto se consigue cambiando la línea en /private/usr/sudoers que permite todos los comandos a los usuarios del grupo admin. Se puede obtener más información a través de la página de manual de sudoers (man sudoers)

Tras efectuar estos cambios, sudo es mucho más seguro y probablemente más seguro que usar root directamente. De todas formas, deberías efectuar el cambio para denegar el acceso de root a través de SSH y usar la autenticación de clave pública.

La realidad

He propuesto argumentos y sugerencias para usar la cuenta de root y para usar sudo. Pero se debe de tener en consideración el rol del ordenador y de los usuarios principales antes de tomar una decisión que pueda ser la más efectiva en cada caso.

La función principal de sudo es permitir a los usuarios acceso limitado a comandos de root con el propósito de distribuir la carga de trabajo del administrador de sistemas. En un sistema con un único usuario, tu eres el único al que puedes distribuir tu carga de trabajo. Si tomas unas pocas precauciones, activar la cuenta de root es perfectamente seguro y puede ser más seguro que la configuración por defecto de sudo. En una máquina con varios usuarios, sudo es un valor añadido y puede ser la mejor forma de proceder. Dadas sus limitaciones, la noción de que sudo es siempre la mejor opción es dudosa. La realidad es que depende de la configuración.

Copyright 2006 Keith Winston – Linux Box Admin
Traducido por Luisma – AIH, con permiso del autor.

   

Resumen de noticias de la semana 12
 

Resumen de noticias de la semana 12 (20 al 26 de Marzo de 2006)
  • Reunión de Hacklabs (Jorge Cortell)
  • Actualización de seguridad para MacOS X (Hispasec)
  • Publicada la versión 2.6.16 de Linux (Slashdot)
  • Firefox 2 viene sin el mecanismo de ping (Kriptopolis)
  • El proyecto OpenBSD en peligro por falta de dinero (Slashdot)
  • Francia multará con 150 euros a los que compartan música online (20 minutos)
  • Windows Vista retrasado al encontrarse problemas que requieren reescribir en 60% de su código (Slasdot - Más Slasdot)
  • Deficiencias en la seguridad de las redes de control de misiles del ejercito norteamericano (Hispasec)
  • Versión Alpha 1 de Firefox 2 (Slashdot)
  • Grave fallo en Sendmail (Hispasec - Slashdot)
  • Tres fallos en Internet Explorer esta semana, dos críticos (Kriptopolis - Slashdot)
  • Ataque DDoS contra el nuevo servicio GRID de Sun Microsystems (Slashdot)
  • Aplazado también el lanzamiento de Office 2007 (elhacker.net - Slashdot)
  • Fallo en IPSec de FreeBSD (Hispasec)


Resumen de noticias de la semana 13
 
Resumen de noticias de la semana 13 (27 de Marzo a 2 de Abril)
  • Multiples vulnerabilidades en RealPlayer y RealOne (Hispasec)
  • Descubierto un bug en Firefox a causa de una rotura sentimental (Schneier - Slashdot)
  • El registrador de dominio Joker.com atacado por un DDoS (Slashdot)
  • Microsoft crea una base pública de bugs (Kriptopolis)
  • Nuevo problema con DRM, esta vez de EMI (ElHacker.net)
  • Sitio ruso vende kits de spyware (ShellSec)
  • Aumento de los ataques contra el bug de Internet Explorer (Slashdot)
  • Parche no oficial para Explorer (Kriptopolis - Slashdot)
  • Microsoft se une a la Alianza OpenDocument (Slashdot)
  • Microsoft desmiente la información sobre Vista (ElHacker.net)
  • Carlos Sanchez Almeida abandona la lucha en la Red (Barrapunto - Kriptopolis)
  • IU denuncia a un ayuntamiento por usar redes P2P (Barrapunto)
  • El Parlamento ruso aplaude los ataques contra determinadas webs (Kriptopolis)
  • Nuevo número de [IN]SECURE Magazine (Kriptopolis)
  • Un virus para móviles se extiende por España (Hispasec)


Resumen de noticias de la semana 14
 
Resumen de noticias de la semana 14 (3 al 9 de Abril de 2006)


Resumen de noticias de la semana 15
 

Resumen de noticias de la semana 15 (10 al 16 de Abril de 2006)
  • Software de virtualización para MacOS X sobre Intel  (Microsiervos)
  • Opera 8.54 corrige vulnerabilidad crítica (ElHacker)
  • La policía australiana publica en Internet sus propias contraseñas (Kriptopolis)
  • Disney y ABC cuelgan en internet sus series gratis (con publicidad) (20minutos)
  • Diversas vulnerabilidades en PHP (Hispasec)
  • Denegación de servicio en sysfs del kernel 2.6 de Linux (Hispasec)
  • Cinco actualizaciones de Microsoft en Abril, incluyendo una acumulativa para varios fallos de IE (Slashdot - Hispasec - Más Hispasec)
  • Final definitivo para el soporte a Windows 98 el 11 de Junio (ElHacker)
  • Aumenta el numero de ataques contra las aplicaciones web (Slashdot)
  • Disponible Firefox 1.5.0.2 que elimina varios fallos (Slashdot - Kriptopolis)
  • El ejercito estadounidense investiga la venta de memorias usb conteniendo datos sensibles en Afganistan (Slashdot)
  • Más fallos en RFID (Kriptopolis)
  • Los Estados Unidos pretenden negociar con los paises europeos el acceso a los datos retenidos por la normativa comunitaria (Kriptopolis)


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 algunos correos apoyando está nueva periodicidad y ninguno en contra. Esperamos que sea del gusto de todos. De todas formas, recordad que aquí tenéis vuestro sitio para opinar.

No me gustaría extenderme demasiado, pero me gustaría opinar sobre la carta publicada por un lector del boletín la semana pasada.
Creo que puede que tenga razón en algunos aspectos que me gustaría destacar, como  el bajo nivel desde hace tiempo en algunos de los bloques y creo que la solución podría estar en un boletín mensual con contenidos un poco mas depurados como habeis decidido.

Quizás se pueda saborear mas un boletín mensual y un poco mas extenso, creo que es una opción realmente acertada. Aun así no podemos dejar de agradecer el trabajo hasta ahora se ha realizado.

Muchas gracias a tod@s.

--------------

Me parece perfecto el cambio en la periocidad si el boletin va ha ganar en calidad y en contenidos.


Que tal Sres Infohackers,

Mi pregunta es acerca de la seguridad que se debe tener con el uso de Skype en la red una empresa y sobre esto que recomendaciones, de seguridad, deben tomarse para el uso de esta herramienta.

Gracias por su respuesta.

El uso de Skype en una red corporativa puede ser muy útil, por el ahorro que la Voz sobre IP permite en llamadas telefónicas, especialmente de larga distancia. Sin embargo, como todos los productos de mensajería instantánea, supone un riesgo añadido de seguridad. En general, estos riesgos suelen ser de dos tipos: unos asociados al producto en sí y a sus posibles vulnerabilidades (como, por ejemplo, el fallo del MSN Messenger que permitía ejecución de código al visualizar una imagen); y otros derivados de las funcionalidades de transmisión de ficheros, que permiten la entrada sin control a la red interna.

En el caso de Skype, el problema se ve acentuado por dos características propias de este software: su habilidad para burlar los firewall y la encriptación. La primera característica es común a más programas de IM, e incluye la posibilidad de usar relays para conectar dos usuarios cuyos firewall no permitan conexiones entrantes, así como el uso de puertos como el 80 (http) o 443 (https) que, por norma general, suelen estar abiertos para salida en el firewall y, además, es difícil que se puedan restringir.

La segunda característica, la encriptación, hace que sea muy complicado usar filtros de contenidos de paquetes para limitar o comprobar el tráfico de Skype, y permite que ficheros maliciosos pasen a través de antivirus perimetrales sin ser detectados. Ante esta situación, la única defensa que queda es el software anti-malware (antivirus, antispyware, etc) de la estación de trabajo y, en última instancia, la capacidad del usuario de no dejarse engañar. Desgraciadamente, está última está siempre muy en entredicho (ver boletín 214). Por otro lado, las estadísticas de los antivirus (ver virustotal.com) indican que ninguno tiene una efectividad del 100%. Por lo tanto, he aquí el verdadero riesgo para la seguridad de Skype.

Un problema adicional es lo difícil que resulta evitar la instalación. Si estamos en una red Windows con dominio, podemos recurrir a políticas para restringir la instalación de este software, o bien filtrar en el proxy el acceso a los sitios de descarga. En cualquier caso, la limitación es complicada, especialmente si se trata de usuarios con portátiles que los usan fuera de la oficina.

Decidir si un software debe ser permitido o no es siempre una decisión compleja y, a menudo, fuente de roces entre los usuarios y los administradores. Siempre hay que buscar un equilibrio entre la seguridad y la funcionalidad. En la mayor parte de los casos, es la formación y la confianza en los usuarios la que puede marcar la diferencia.


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.orgrg
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: router1.png (image/png) ]
[Adjunto no mostrado: 2/ (application/octet-stream) ]
[Adjunto no mostrado: 1/ (application/octet-stream) ]