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