Google EL TIPO DE INFORMATICA

martes, 24 de julio de 2012

Leer Conversaciones Guardadas de Skype con SQLiteBrowser

En estos días se ha estado hablando de Skype en la red debido a la publicación de su código fuente y también a un problema que causaba que mensajes llegaran a personas que nisiquiera estaban en la lista de contactos. Así que quise aprovechar para hablarles de algo que encontré hace un tiempo mientras revisaba los archivos de datos de Skype, por simple curiosidad. Y es que el historial de conversaciónes o chat y otras informaciónes (como la lista de contactos) del usuario son almacenadas en un archivo de base de datos, y lo mejor, no esta encriptado ni nada parecido. Y todavía mejor, por default Skype almacena un historial de todas las conversaciónes, a menos claro que le digamos lo contrario, cosa que por lo que he visto muy poca gente hace.

En Windows 7, los archivos de datos de Skype se almacenan en la dirección "C:\Users\nombre-de-usuario-de-windows\AppData\Roaming\Skype\", dentro de esta carpeta encontraremos una o varias carpetas con los nombres de usuarios de Skype que se hayan logeado en esa computadora, en la que encontraremos estos archivos:


Archivos Skype

Como pueden ver en el gráfico anterior esta señalado el archivo "main.db", este es el archivo que contiene el historial de chat, los contactos, etc. Aquí es entonces donde utilizaremos el programa "SQLite Database Browser" que pueden descargar desde este link. Verán que es bastante sencillo de utilizar, solo hacen doble clic encima del ejecutable, luego hacen clic en "File--> Open Database" y buscamos el archivo "main.db" en la ruta mencionada anteriormente o donde lo hayamos copiado. Al abrir nuestro archivo lo primero que veremos sera la estructura de la base de datos, como se ve a continuación:

Base de datos Skype

En esta ventana seleccionamos el tab "Browse Data", y luego en la sección "Table" seleccionamos la tabla "Messages". Esta tabla es la que contiene el historia de Chat del usuario. Como verán, aquí aparecen las demás tablas que también pueden contener información interesante. En este caso seleccionaremos "Messages":

Archivo de Datos Skype

Esta tabla contiene muchas columnas, para ver el mensaje transmitido tendremos que movernos hacia la derecha en la ventana hasta la columna "body_xml". Lo bueno es que esta herramienta nos permite también ejecutar Queries SQL en esta base de datos, lo que nos facilitaría la lectura de los mensajes, para esto nos movemos al tab "Execute SQL", y en la sección "SQL String:" podemos escribir nuestro query y filtrar los mensajes. Las columnas mas importantes son author, from_dispname, dialog_partner y body_xml, así que podríamos ejecutar el siguiente query:

Archivos de Datos Skye

Como ven, ahora nos resultara mas cómodo leer todas las conversiones. Ahora bien, que hacer para evitar que alguien pueda leer nuestras conversaciones de esta manera? Lo primero primero seria decirle a Skype que no conserve nuestras conversaciones, esto se hace en "Tools --> Options --> Privacy" en la sección "Keep history for" seleccionamos "no history":

Configuracion Skype


Otra opcion seria borrar periódicamente este log, como ven en el gráfico anterior hay un botón "clear hostory" que se encargaría de esto. En la mayoría de los casos creo que la mejor opción seria la primera, no guardar historial de conversaciónes. Así que ya saben, la próxima vez que tengan la computadora de un amigo o compañero en sus manos y este usa Skype... no sean malos y adviertanle sobre el setting para eliminar las conversaciónes :) . Bueno, espero como siempre que esta información les haya sido de utilidad (tanto como a mi :P ).

viernes, 13 de julio de 2012

Un Poco de IPTables Parte 3: Redireccionando Logs

Siguiendo con lo que ahora se ha convertido en una serie de post de IPTables, voy a hablarles de como manejar los logs de IPTables, configurar cuales eventos que queremos escribir, agregar algún prefijo y redireccionarlos a un archivo especifico en el equipo, ya que por default los logs de IPTables se almacenan en el archivo "/var/log/kern.log". Para esto aplicaremos algunas reglas en IPTables y luego configuraremos nuestro syslog server (utilizaremos Syslog-NG) para indicar que queremos tener un archivo aparte únicamente con los log de IPTables. 

Lo primero que debemos hacer es determinar que tanto queremos que IPTables nos registre, si queremos que registre cada paquete que entre o salga a nuestra red, o si solo queremos que registre los paquetes que hayan sido "Dropeados" o descartados. La opción mas recomendable es logear todo lo que pase por nuestro Firewall, ya sea permitido o bloqueado, ya que esto nos permitirá identificar mas fácil algún problema de conexión, como auditoría en caso de que necesitemos localizar conexiones salientes o entrantes hacia algún sitio especifico o también para generar reportes de uso o ancho de banda. Hay que tener en cuenta que con esta opción nuestro archivo de log crecerá mucho mas rápido, dependiendo de la actividad de nuestra red. Para esto haremos lo siguiente: Supongamos en este ejemplo que nuestro firewall tiene 2 interfaces, la eth0 que esta conectada a Internet y la eth1esta conectada a nuestra red LAN, queremos entonces registrar todo lo que entre o salga hacia Internet, agregamos las siguientes reglas (antes de las demás reglas que hayamos definido para que se registre cada paquete antes de tomar alguna decisión sobre el mismo)

-A FORWARD -o eth0 -j LOG --log-level 7 --log-prefix IPTABLES-BANDWIDTH_OUT: 
-A FORWARD -i eth0 -j LOG --log-level 7 --log-prefix IPTABLES-BANDWIDTH_IN: 

En la primera linea le decimos a IPTables que todos los paquetes que salga desde nuestra red LAN a través de la interfase eth0 (-o eth0) le aplique la acción LOG (-j LOG), esta entrada en el log sera nivel 7 (--log-level 7) y le decimos que agregue el prefijo "IPTABLES-BANDWIDTH_OUT:" (--log-prefix), este prefijo lo utilizaremos mas adelante como filtro para enviar este tipo de eventos hacia un archivo especifico. En este prefijo pueden poner cualquier otra cosa que les haga sentido, de modo que cuando vean un evento en el log con este prefijo sepan de donde viene y como se produjo. En la segunda linea hacemos lo mismo, lo único que decimos que registro todo paquete entrante (-i) por la interface eth0, en este caso serian paquetes provenientes de Internet, y en la parte final del prefijo sustituimos OUT por IN para diferenciar los que son paquetes salientes con los entrantes.

Podemos también registrar los paquetes que han sido descartados, o que no encontraron ninguna regla que coincida permitiendo o denegando el paquete. Como les había mencionado en la entrada anterior sobre IPTables, podemos tener una acción por defecto que se aplicara a los paquetes que no coincidan con ninguna regla, por esto agregamos las siguientes reglas al final de las reglas de cada cadena, por ejemplo, al final de las reglas de INPUT, de modo que luego de que el paquete haya sido evaluado por cada y regla y no coincida, se registre este paquete antes de aplicar la regla default. Por ejemplo, supongamos que tenemos definidas varias reglas en nuestro firewall, una permitirá el trafico HTTP/S y POP3 hacia Internet desde la LAN hacia Internet, luego de estas agregaremos la siguientes reglas para logear todo lo que no se corresponda a lo que hemos definido:

-A FORWARD -p tcp -s LAN -d 0/0 --dport 80 -j ACCEPT
-A FORWARD -p tcp -s LAN -d 0/0 --dport 443 -j ACCEPT
-A FORWARD -p tcp -s LAN -d 0/0 --dport 110 -j ACCEPT
-A FORWARD -j LOG --log-level 7 --log-prefix IPTABLES-FORWARD-DROP:
-A FORWARD -j DROP

Como ven, tenemos aquí las reglas de ejemplo definidas que permiten ciertos paquetes, luego en la cuarta linea indicamos que todo lo que haya llegado a este punto sea logeado y le agregemos el prefijo "IPTABLES-FORWARD-DROP:", así reconoceremos los paquetes con este prefijo y sabremos que fueron descartados en la cadena FORWARD. Esto mismo lo podemos aplicar tambien en INPUT, OUTPUT o cualquier otra que hayamos definido. En el caso de que utilicemos las primeras reglas que registran todo el trafico entrante y saliente, es buena idea también utilizar estas ultimas, así podemos diferenciar cuales eventos corresponden a paquetes bloqueados.

Hasta ahora ya tenemos a IPTables generando logs, pero los estará creando posiblemente en el archivo "kern.log", donde se encontraran también otros tipos de eventos. Ahora veremos como separa los logs de IPTables y almacenarlos en un archivo individual con Syslog-NG.

  • Configuración Syslog-NG

El archivo que crearemos para almacenar el log de IPTables lo llamaremos iptables.log y lo crearemos en /var/log. Con esta informacion, vamos al archivo "/etc/syslog-ng/syslog-ng.conf" y en la sección "#destinations" agregamos la siguiente linea:

destination d_iptables { file("/var/log/iptables.log"); };

Aquí creamos un "destino" que llame "d_iptables" y le indicamos hacia adonde apuntara, que en este caso se nuestro archivo iptables.log (tengan en cuenta que luego del corchete hay un espacio en blanco). Luego nos movemos a la sección "filters" donde crearemos un filtro que nos permitirá separar los eventos de IPTables basándonos en los prefijos que indicamos anteriormente. 

filter f_iptables { match("IPTABLES") ; }'
filter f_not-iptables { not match("IPTABLES") ; };

Aquí agregamos 2 lineas (o filtros), uno que aplicara a los eventos que contengan las palabras IPTABLES (esta palabra la agregamos en cada prefijo) y otro para los eventos que NO contengan estas palabras, el segundo lo utilizamos para evitar que los eventos de IPTables se continúen almacenando en el archivo kern.log. Nos moveremos entonces ya a la sección "log", donde buscaremos el log que define los eventos que se almacenan en el archivo "kern.log" y agregaremos el segundo filtro que creamos, se vera entonces de esta forma:

log {
         source(s_all);
         filter(f_kern);
         filter(f_not_iptables);
         destination(df_kern);
}

Luego agregaremos entonces nuestro nuevo log indicando el destino  filtro que creamos:

log {
         source(s_all);
         filter(f_iptables);
         destination(d_iptables);
}


Al agregar esto salvamos el archivo y reiniciamos el servicio (/etc/init.d/syslog-ng restart). Con esto estaremos recibiendo los eventos de IPTables en el archivo definido. Si queremos ver lo que esta pasando entonces por nuestra red (en caso de que hayan configurado la primera opción de logs) o como va creciendo el archivo de log, podemos ejecutar:

# tail -f /var/log/iptables.log

Para ver solo los que estén siendo descartados por IPTables podemos agregar :

# tail -f /var/log/iptables.log | grep DROP


Bien, hasta aquí mi pequeño tip de IPTables, como siempre, espero que esto les sea de utilidad.

martes, 12 de junio de 2012

Tratando de Analizar (superficialmente) un Malware

Antes que nada quiero aclarar que no me refiero a un análisis profundo de un malware, a lo que me refiero es a ver las actividades que realiza, adonde intenta conectarse y que modifica en el sistema, a fin de que podamos tomar medidas para evitar la infección y facilitar la desinfección en caso de que uno de nuestros usuarios haya decidido ejecutar el malware antes de llamarnos, como usualmente pasa. Usare algunas herramientas, tanto locales como online, que nos ayudan a conocer un poco las intensiones del malware en cuestión y como intenta hacer la infección del equipo que lo ejecute. Teniendo esto claro, podemos continuar :) . En estos días recibí un correo SPAM que decía venir de un scanner HP, y como es normal en este tipo de mensajes traía consigo un archivo anexo ZIP, la diferencia con los que generalmente llegan es que este en lugar de contener un ejecutable contenía un archivo HTML, a continuación el mensaje:

Malware anexo

El archivo anexo se veía así al abrirlo con WinRAR:

Malware Anexo

Lo primero que hice fue crear una regla en el mail server para bloquear este mensaje especifico (por "subject", por "from", etc.) para tratar de evitar que llegue a otros usuarios. Luego subí mi  maquina virtual con XP que tengo como conejillo de indias. Configure la red de la maquina virtual (que en lo adelante llamare "la víctima") en modo "Bridge", la configure en el mismo rango IP de mi computadora host. La IP de mi maquina virtual sera 192.168.137.2 y la del host es 192.168.137.1, se necesita que tengan conexion entre si para poder utilizar el equipo host como proxy para la maquina virtual (como se vera mas adelante). Luego abrí con "notepad" el archivo  para ver el contenido sin ejecutarlo:

Archivo en Notepad

No se mucho de programación o html, pero no hace falta ser un experto para darse cuenta que esta pagina ejecuta un script y que esta aparentemente codificado. Haciendo una breve búsqueda en Google con la primera linea de este script encontre este enlace a Pastebin, de donde aparentemente viene el código. Luego encontré también este site que permite decodificarlo. Bueno, es hora entonces de verlo en acción, hice doble clic en el archivo HTML para que se ejecutara en mi maquina virtual, abrió con Internet Explorer 6 (que es el que tengo en mi maquina para pruebas) y presento el siguiente mensaje:

Descarga del Malware

El navegador me indica que este archivo esta intentando ejecutar cierto tipo de contenido que esta bloqueado, y que si quiero habilitarlo debo hacer clic en OK, hacer clic en la franja amarilla y seleccionar "Allow Bloked Content". Es posible que esta advertencia evite que algunos usuarios ejecuten este script, pero es seguro que la mayoría dará clic sin leer en "OK" y luego ejecutaran el código. Como mi intención es probar el script procedí a permitir que este se ejecutara, lo que hizo que el navegador me diera otra alerta mas sobre el contenido:

Descarga del Malware

Cualquiera pensaría que con tantas alertas los usuarios no ejecutarian este tipo de código, pero como todos sabemos los usuarios aman los botones "YES" y ciegamente hacen clic sobre ellos, así que muchos usuarios volaran esta advertencia y ejecutaran el código, que es lo que hice para esta prueba. Al hacer clic en "Yes" e ignorar la advertencia me devolvió el siguiente error:

Descarga del Malware

Si se fijan en la barra de estado del navegador, vemos que aunque se presenta el mensaje diciendo que se aborto la operación, Internet Explorer esta abriendo una pagina en un dominio de Rusia al puerto 8080 de ese servidor. En ese momento ejecute en una ventana de comandos el comando "netstat -na" para ver las conexiones que estaba haciendo mi maquina "víctima" hacia afuera:

Comando Netstat

Ahora necesitamos ver la conversación entre ese servidor y nuestra PC víctima, para esto configuraremos Internet Explorer en la maquina virtual para que utilice un proxy que correremos en el equipo Host, asi capturaremos los "Request" hacia el servidor en Internet y tambien las respuestas de este. Podríamos utilizar también un sniffer como Wireshark en nuestro Host y capturar todo el trafico entrante y saliente a nuestra maquina virtual, pero en este caso con el proxy es suficiente (y mas facil).

  • Monitoreando las conexiones a Internet con Burp Suite Free
"Burp Suite"es un proxy que permite entre otras cosas el ver las peticiones y respuestas a Web servers, podemos también modificarlas on line. Pueden descargarlo de este link. Esta hecho en Java, por lo cual requeriran tener instalado el RunTime. Una vez lo hayan descargado, lo ejecutan y se mueven al tab "proxy", y aquí al tab "options". En este tab le indicamos en que interface y en que puerto escuchara las peticiones, debe verse de esta manera:

Burp Proxy

Deben quitar la selección de la opción "Listen on loopback interface only" para que el programa escuche en todas las interfaces, en mi caso elegi el puerto 8080. En esta misma ventana deben también seleccionar la opción "intercept if" debajo de la sección "intercept server responses", para poder capturar también las respuestas de los servidores Web. Ya teniendo el proxy preparado para capturar, configuramos el navegador en nuestra maquina virtual para que lo utilice, en el caso de mi maquina virtual utilizo Internet Explorer 6 (lo se, un poco viejo, pero esa es la idea). Por si no saben como hacerlo, abren el Internet Explorer, luego hacen clic en Tools--> Internet Options --> Connections --> Lan Settings. En el caso de mi configuracion se veria de esta forma:



Ahora, volvemos a ejecutar de nuevo el archivo HTML y esperamos a recibir la solicitud de conexion al proxy en nuestro equipo. Cada conexion (http o https) que intente hacer nuestro equipo virtual a Internet pasara por Burp donde podremos revisar cada solicitud antes de aprobar que salga a su destino, en este caso el dominio ".ru".  Al ejecutar el archivo podemos ver la primera solicitud que hace:

Burp Proxy

Como vemos hemos capturado la primera solicitud la hace al sitio "http://uzindexation.ru:8080" y esta solicitando la pagina "/forum/showthread.php?page...". Para que esta solicitud pueda llegar al servidor debemos dar clic en esta ventana en el boton "Forward", y esperamos entonces por la respuesta del servidor, que llegara en unos segundos y verán algo como lo siguiente:

Burp Proxy

El servidor responde con otro script, aparentemente también codifcado. Podemos copiar todo este código, guardarlo en un documento html y subirlo a este site que les mencione al principio, aqui podemos decodificarlo y ver que es lo que esta transfiriéndole ese servidor a nuestro equipo. Pero para seguir observando el Malware, hacemos clic en "Forward" en esta ventana para permitir que este paquete llegue a nuestra maquina virtual. Al hacer esto veremos pronto otra solicitud que hace la maquina al servidor del atacante:

Burp Proxy

Ahora nuestro equipo víctima hace otra solicitud al servidor "malicioso", solicita la ejecución de un archivo PHP (/forum/data/ap2.php), hacemos clic nuevamente en "Forward" para permitir esta solicitud y esperar la respuesta del servidor. Como se puede ver en los headers, en esta ocasión el servidor le envía a la maquina víctima un archivo PDF, es muy posible que sea un archivo "especialmente manipulado" que explote alguna vulnerabilidad en Acrobat Reader y se use para descargar/ejecutar codigo malicioso en el equipo víctima y continuar la infección del equipo. La ventaja de usar un proxy en el medio de la conexion entre la víctima y el atacante es que podemos facilmente reconstruir el archivo que envía el servidor y salvarlo en nuestro equipo. Para esto solo tenemos que hacer clic derecho en el cuerpo del reply del servidor, como se ve en el gráfico siguiente, y seleccionar "copy to file" e indicarle donde queremos guardar el archivo y con que nombre. En mi caso, lo nombre "pdf-bad.pdf".

Burp Proxy

  • Analizando el Archivo en Virus Total
Teniendo ya grabado nuestro PDF de dudosa reputación, podemos subirlo a Virus Total para analizarlo contra los motores de las principales casas antivirus. Por si no lo conocían, VirusTotal es un servicio gratuito que permite analizar tanto archivos como direcciones Web y como les dije los analiza con las versiones actuales de los principales motores antivirus. Es muy utilizada tanto para comprobar archivos sospechosos como nuestro PDF, como para comprobar que tan detectable seria ante los antivirus un ejecutable que hayamos creado. Como verán el PDF es detectado en 6 de los 42 motores antivirus contra los que VirusTotal lo evaluó, lo cual nos confirma que este PDF se trae algo entre manos, y que aparentemente es una explota alguna vulnerabilidad reciente ya que pocos motores antivirus lo reconocen (a la fecha en que hice la evaluacion), como se ve en el siguiente gráfico:

Virus Total


Hasta ahora sabemos que el archivo HTML que llego por correo contiene un script (codificado) que envía al navegador a un sitio web desde donde se ejecuta un archivo PHP que descarga a la maquina víctima un archivo PDF especialmente modificado que aparentemente explota una vulnerabilidad en Acrobat Reader. La versión que tengo instalada en la maquina virtual es la version 9.3 y esta es evidentemente vulnerable al exploit que contiene este PDF, ya que al permitir que llegue a la maquina victima, Internet Explorer llama a Acrobat Reader para abrir el archivo malicioso y al ejecutarlo (en background) realizara esta otra petición:

Burp Proxy

Aquí la maquina víctima solicita otra pagina PHP, a lo que el servidor responde con el archivo que se ve en el gráfico siguiente. Nuestro amigo en Rusia envía a nuestra victima un archivo ejecutable (contacts.exe), el nombre de este archivo varía, en otras ocasiones el servidor enviar "calc.exe". Al igual que hicimos con el archivo PDF, podemos copiar todo este contenido, guardarlo en un archivo en nuestra computadora, y subirlo a VirusTotal para ver como lo reconocen los motores antivirus.

Burp Proxy

Al momento en que subí este ejecutable a Virus Total, solo era reconocido por 4 casas antivirus, lo que quiere decir que es muy probable que si uno de los usuarios lo hubiese ejecutado, el antivirus no lo hubiese detectado. A esta altura ya tenemos el archivo ejecutable que se descarga del servidor del atacante, ahora queremos saber que como se comportaria este ejecutable, una forma seria usando la misma descripción que dan las casa antivirus que lo detectan, pero en el caso de este ejecutable las pocas que lo detectan lo describen de forma genérica. A continuacion veremos una forma sencilla de saber las actividades que realizaria este ejecutable en nuestro equipo sin tener que ejecutarlo nosotros.

  • Utilizando un Sandbox para analizar el Ejecutable

En esta parte utilizaremos el site GFI Threat Track, este sitio nos permite subir una muestra de un archivo para su análisis, luego nos envían un elegante reporte con todas las actividades que realiza el archivo que subimos, los archivos que crea, las conexiones que intenta hacer y hacia adonde, las claves del registro que modifica, etc., lo que nos economiza tener que seguirle nosotros mismo el rastro a este malware en el equipo virtual de prueba que tenemos, y lo mejor, el servicio es gratuito! Luego de unos minutos de haber subido el archivo, recibiremos un correo con el reporte anexo de todas las actividades que detectaron realiza nuestro archivo, el reporte es bien detallado y tiene varias paginas, nos servirá de ayuda para detectar este malware en otros equipos posiblemente infectados y evitar la infección de otros. En el siguiente gráfico se muestran algunas partes del reporte, porque como les dije tiene varias paginas. En esta gráfica se muestra en resumen algunas de las actividades que realiza este ejecutable:


Como pueden ver, nuestro amigo crea archivo ocultos, crea mutaciones de el mismo y borra el archivo original que descarga, hace conexiones de red, etc. Mas adelante en el reporte veremos los archivos que crea o modifica este ejecutable, las claves del registro modificadas y hacia adonde intenta conectarse, lo cual nos servirá para bloquear esta IP en nuestro Firewall:



Resumiendo, podemos decir que el atacante envía masivamente correos con un archivo HTML comprimido en un ZIP haciendo creer que el mismo es enviado por un Scanner en la red. El archivo HTML posee un script camuflajeado que solicita la descarga de un archivo PDF manipulado que explota cierta vulnerabilidad en Acrobat Reader (aparentemente en la versión 9.3), el codigo que se ejecuta tras explotar la vulnerabilidad descarga y ejecuta un archivo "EXE". Una vez este archivo se ejecuta, periódicamente nuestro equipo infectado envia informacion hacia varios servidores (intenta varios servidores en caso de que no pueda conectarse al primero de donde descargo el malware). La información que transmite el equipo infectado es aparentemente encriptada. Bueno, los mas avanzados dirán que esto no es nada nuevo, que es la forma tradicional en la que trabajan los malwares hoy en día, eso es cierto, pero creo que es interesante que nosotros mismos podamos ver por lo menos por arriba como se realizan estas actividades. 

A continuación algunas recomendaciones que entiendo nos pueden ayudar a evitar que este tipo de malware infecte a nuestros usuarios:

  1. Educar a los usuarios para que reconozcan este tipo de amenazas y entiendan el riesgo que estos traen consigo, enseñarlos a no abrir o ejecutar ningún archivo anexo que venga en un correo no solicitado o que no reconozcan la dirección o el remitente, y claro, a contenerse las ganas de hacer clic en todos los "OK" que se les presenten.
  2. Mantener los sistemas operativos y aplicaciones actualizadas, el PDF que descarga el archivo HTML no ejecuta el código que descarga el ejecutable si se abre con versiones recientes de Acrobat Reader.
  3. Filtrar el trafico de salida lo mas que se pueda, en el caso de este malware, intenta hacer conexiones a un puerto no standar (8080), muy pocas aplicaciones que utilicemos utilizaran este puerto, para las que lo usen podemos permitirlo, pero para la mayoría del trafico solo se debería permitir la conexion a traves de proxy y a los puertos standar (80 para HTTP y 443 para HTTPS).
  4. Restringir en lo posible el acceso a Internet de los usuarios, en el caso de que un usuario reciba y ejecute un archivo como este, si solo tiene permiso a navegar en ciertos sitios, este malware no se ejecutaria ya que no podría descargar ni el PDF ni el Ejecutable.
  5. Por ultimo tener un antivirus y mantenerlo actualizado, tanto en los clientes como en nuestro servidor de correo. Lo dejo de ultimo porque como pudimos ver en este ejemplo muy pocos antivirus (solo 4 de 42) pudieron detectar el archivo malicioso, por lo que no podemos apostar toda la seguridad de nuestro sistema a los antivirus.
Bueno, espero como siempre que esto les haya parecido interesante y sobre todo que les haya servido de ayuda.

Hasta el Próximo!

jueves, 10 de mayo de 2012

Convertir una Presentacion de PowerPoint en ScreenSaver

Recientemente he estado trabajando en unos tips de seguridad para los usuarios en la compañía donde trabajo, como parte de un pequeño programa de "Security Awareness". La presentación es corta y básicamente incluye unos consejos sobre como manejar el correo de una forma segura y tener precaución a la hora de recibir correos, especialmente correos que contengan archivos anexos. El caso es que aparte de la presentación, pensé también en crearles un Screen Saver con los mismos tips para que cada 5 o 10 minutos de inactividad la computadora empiece a mostrárselos, y ver si así (aunque sea de manera subconsciente) asimilen y apliquen algunos de estos tips, por lo que empecé a buscar la forma de convertir mi presentación (con unas cuantas modificaciones para que se vea un poco animada) en Screen Saver, o ".scr". La primera opción que se me ocurrio fue utilizar el Screen Saver que trae Windows por defecto (My Pictures Slideshow) que te permite utilizar fotos que tengas en una carpeta. Para esto es necesario primero guardar todos los Slides de tu presentación como archivos JPG, esto se hace de la siguiente manera:
  1. En PowerPoint, hacemos clic en "Save as"
  2. Elegimos la opción "Other Formats"
  3. Seleccionamos entonces "JPGE File Interchange Format (*.jpg)
  4. Luego seleccionamos "Every Slide" y seleccionamos la carpeta donde guardaremos los slides
Luego, tomamos esos esos JPG's y los copiamos a una carpeta compartida en la red a la cual los usuarios que queremos que tengan este screen saver deben tener acceso (solo de lectura). Si la computadora tiene Windows XP, nos vamos a la sección de Screen Savers y seleccionamos el screen saver llamado "My Pictures Slideshow" y hacemos clic en "Settings", aquí nos saldrán las opciones como el tiempo en que las fotos cambiaran, el tamaño entre otras, haremos clic en el botón "Browse" y nos moveremos al icono "My Network Places" y buscamos el equipo que contiene la carpeta compartida con los JPG que grabamos de nuestro PPT y  hacemos clic en OK. Con esto ya tenemos un Screen Saver con los datos de la presentación.

Pero este método, aunque es sencillo, tiene un par de inconvenientes. Lo primero es que se pierde cualquier animación que hayamos incluido en la presentación, como efectos en las letras o algún sonido que contenga la presentación, lo que puede tornar nuestro screen saver un poco aburrido (que de hecho seguro que lo sera para la mayoría de los usuarios) Tambien tiene el inconveniente de que hay que configurarlo usuario por usuario, porque este screen saver no tiene una forma de configurarlo via una GPO por ejemplo (al menos, yo no encontré la forma, quizás a se pueda a traves del registro). La mejor forma para mi es usar un programa que haga la conversión de PPT a SCR porque asi traerá las animaciones y sera mas fácil copiarle el archivo a las computadoras e indicar por GPO que usen ese screen saver. Luego de una larga búsqueda en Google, donde encontré muchisimos programas que lo hacen, la gran mayoría requería licencia y los que me daban el Demo entonces incluían una marca al Screen Saver, encontré uno sencillo y lo mejor, no me incluía ninguna marca o limitaba la presentación, llamado "Presentation to Screen Saver Converter for PowerPoint 1.0" que pueden descargarlo (o comprarlo) desde este link

El programa es bastante sencillo, solo hay le decimos donde esta nuestra presentación, agregamos algún archivos de audio si queremos, y le indicamos donde queremos guardar nuestro nuevo screen saver y listo. A continuación un "print screen" de la ventana del programa:

Powerpoint to Screen Saver

Una vez hemos incluido estos datos hacemos clic en "Convert" y ya tendremos nuestro Screen Saver con los efectos y animaciones que hayamos incluido en nuestra presentación y podemos distribuirlo.

miércoles, 4 de abril de 2012

Estudiando para el Examen 70-648: Un poco de IPv6

Como el titulo de este post dice, me encuentro estudiando para el examen de Microsoft 70-648, este examen es para migrar la certificación MCSA de Windows Server 2003 a Windows Server 2008, ahora llamados "Microsoft Certified Techology Specialist", ya que cambiaron el nombre de las certificaciones. Como ya soy MCSA en Server 2003 el tomar este examen me economiza 2 exámenes para certificarme como  "MCITP: Server Administrator", el 70-640 y el 70-642, y solo me faltaría tomar el 70-646. Si quieren mas información sobre esta certificación pueden visitar este sitio. Bueno, el caso es que compre el libro de preparación para este examen y ya empece a leerlo. Hay muchas cosas que permanecen igual que en Windows Server 2003, pero también hay cosas nuevas y mejoradas, como se ira viendo mas adelante. Decidí entonces ir haciendo un resumen de cada lección del libro, esto me ayuda a mi a retener mejor cada lección (ya que encuentro que escribirlas me ayuda a aprender mas fácil mas que solo leer), y también les sirve a cualquiera de ustedes que también este pensando en tomar este examen, o que simplemente quieran refrescar cosas que ya saben.

La primera lección es sobre configuración de IPv4 e IPv6, pero no se habla mucho sobre IPv4, ya que se da por sentado es que algo que un MCSA debe manejar, cosas como las clases de IPv4, Subneting, VLSM y direcciones APIPA. Hace mas hincapié en la configuración de IPv6 y eso es lo que haré en este post. Esto no sera una explicacion completa del protocolo IPv6, solo sera un resumen de lo que es necesario saber para configurar IPv6 en Windows Server 2008.

  • Porque  necesitamos IPv6?
Los bloques de direcciones IPv4 publicas se están acabando, gracias a NAT se ha podido extender la vida del protocolo IP versión 4 que todos conocemos pero ya se están agotando las direcciones IPv4 publicas y la migración a IPv6 cada dia se hace mas necesaria. Como saben IPv4 ofrece aproximadamente 4.3 billones de direcciones, ese era un numero grande hace unos años atrás, pero hoy día no son suficientes ya que una sola persona puede tener varios dispositivos conectados a Internet y cada dispositivo necesitara una IP para salir a Internet. Este es el principal problema (diria yo) que viene a corregir IPv6, la cantidad de direcciones IP. Dado que una dirección IPv4 es un numero de 32 bits y que cada uno de estos 32 bit solo puede tener 2 valores (1 o 0), IPv4 nos ofrece un espacio de direcciones disponibles de 2^32,  que serian unos 4,294,967,296 direcciones.  Del lado de IPv6 las direcciones están compuestas por 128 bits en lugar de 32. Siguiendo la misma lógica anterior tendríamos 2^128, lo que seria igual a 340,282,366,920,938,463,463,374,607,431,768,211,456 o mejor expresado 3.4 x 10^38 direcciones IP disponibles, lo cual parece ser  una cantidad suficiente de direcciones no creen?.

  • Sintaxis de una dirección IPv6
Las direcciones IPv6 no se expresan de la manera en que expresamos las direcciones IPv4 tradicionales; los 32 bits de la dirección eran separados en 4 grupos de 8 bits (binarios) convertidos a números decimales separados por puntos, como "192.168.1.2". Ahora con IPv6 los 128 bits se dividen en 8 grupos de 16bits pero en lugar de ser expresados en forma decimal son expresados en notación Hexadecimal, de la siguiente manera:
21dc:0053:0000:0000:03ad:003f:af37:8d62

Pero esta representación puede ser simplificada eliminando los ceros (0) que encabezan cada bloque, utilizando esto la dirección anterior pudiera expresarse de la siguiente manera:

21dc:53:0:0:3ad:3f:af37:8d62

Otra forma de simplificar las direcciones IPv6 es sustituir los bloques continuos que están compuestos solo de ceros por 2 puntos seguidos, o sea. "::". Por ejemplo, en la dirección del ejemplo, el 3er y 4to bloque (de izquierda a derecha) esta compuesto solo de ceros, por lo que podemos sustituir estos 2 bloques por "::",  quedaría entonces de esta forma:
21dc:53::3ad:3f:af37:8d62 

Hay que tomar en cuenta tambien que en IPv6 la mascara de red ya no se expresa de la forma tradicional de IPv4, en forma decimal separados por puntos (255.255.255.0). Ahora se expresan siempre como se expresan con CIDR (Classless Inter-domain  Routing), con la notacion usando "Slash" ("/"), por ejemplo "/64". La antigua notación de la mascara no se utiliza en IPv6.

  • Tipos de Direcciones IPv6
En IPv6 tenemos 3 tipos de direcciones, Unicast, Multicast y Anycast:

- Direcciones Unicast: Al igual que en IPv4, las direcciones Unicast son direcciones que identifican un host, solo que ahora en IPv6 no identifican un host sino una "interface". En IPv4 un equipo era identificado por una IP y en algunos casos un equipo podría tener varias direcciones IP (multihome). En IPv6 la IP identifica únicamente una interface en especifico en el Host, y esto es lo que identifican las direcciones Unicast. Estas son las direcciones IP que utilizamos mas frecuentemente en una red o en Internet. Un paquete dirigido a una dirección Unicast sera recibido solo por una interface en la red.

- Direcciones Multicast: Este tipo de direcciones también se utilizan en IPv4, identifican múltiples interfaces. Un paquete dirigido a una dirección Multicast sera recibido por varios equipos (o interfaces).

- Direcciones Anycast: Este tipo de direcciones no se encuentra en IPv4, es intrucido por IPv6. Al igual que las direcciones Multicast las direcciones Anycast indentifican varias interfaces, con la direferencia de que el paquete enviado a una de estas direcciones no sera recibida por todas las interfaces que posean esta direccion sino únicamente por la mas cercana (en terminos de routing) al origen del paquete. Es algo entre una direccion multicast y una direccion unicast ya que el paquete es recibido por una sola interface. Este tipo de coomunicacion se le llama "uno-a-uno-de-muchos" (one-to-one-of-many).

  • Direcciones Unicast
Dentro de las direcciones Unicast, que como dijimos son las que se utilizan para comunicaciones uno-a-uno, tenemos 3 tipos principales de direcciones, Global, Link-Local, Site-Local y direcciones Especiales.

- Global Unicast: Las direcciones Global son las direcciones equivalentes a las direcciones publicas de IPv4, o sea que estas direcciones son ruteadas en Internet. Estas direcciones se reconocen porque el prefijo siempre es "001". Estas direcciones están formadas de la siguiente manera: Como dijimos, los 3 primeros bits de la dirección o "Format Prefix" o "FP", que siempre es "001". Los siguientes 13 bits son asignados por IANA, esto es conocido como "Top Level Aggregator" o "TLA", estos son asignados a los registers de Internet y estos a su vez los asignan a grandes proveedores de Internet o ISP. Luego siguen 8 bit que se encuentran reservados. Le siguen 24 bits contienen el "Next Level Aggregator" o "NLA", estos identifican a clientes o sitios específicos, estos permiten a los ISP crear múltiples niveles de jerarquía dentro de su red para organizar el direccionamiento y el enrutamiento. Luego siguen los 16 bit del "Site Level Aggregator" o "SLA" que se utilizan para identificar subredes dentro de una organización, también son utilizados por ISP's menores. Los últimos 64 bits identifican la interface, a estos se les llama "Extended Unique Identifier" o "EUI-64".

IPV6

- Link-Local: Estas direcciones son equivalentes a las direcciones APIPA en IPv4, el limite o alcance de estas direcciones es el link local, o sea, la red interna, por lo que NO son ruteadas. Se pueden identificar por su prefijo "fe8". Esta dirección es configurada automáticamente.

- Site-Local: Estas direcciones son equivalentes a las direcciones privadas de IPv4, o sea, las direcciones que usamos a diario en redes internas como "192.168.1.0" o "10.0.0.0". El prefijo de estas direcciones es "fec0".

- Especiales: Hay 2 direcciones especiales, iguales a 2 direcciones especiales usadas tambien en IPv4, la dirección "loop-back" y la llamada dirección "no especificada" o "unspecified". La dirección de "loop-back" en IPv4 es "127.0.0.1", ahora en IPv6 es "0:0:0:0:0:0:0:1" o expresada de manera simplificada "::0". La dirección "no especificada" en IPv4 se expresa como "0/0", en IPv6 ahora se expresa "0:0:0:0:0:0:0:0" o de forma simplificada seria "::".

  • Direcciones Multicast
Como decíamos al inicio, las direcciones Multicast pueden ser usadas por varias interfaces, lo que permite que un paquete sea dirigido a varios equipos o Interfaces, a diferencia de las direcciones Unicast en las que el paquete es destinado a una sola interface. Las direcciones Multicast se reconocen porque siempre empiezan con 11111111 o "ff".

Bueno, hasta aquí lo que considero mas importante del contenido de IPv6, y creo que es lo mas importante a tener en cuenta para ir adaptandonos a IPv6. Espero que les sea de utilidad, sobre todo si piensan como yo tomar el examen 70-648. Mas adelante seguiré subiendo resúmenes de los demas capitulos a medida que vaya avanzando.