Mounting lvm partitions: get into the dark depths of disk storage

Buenas amigos, hoy traigo este artículo desde las oscuras tierras donde moran los sysadmins. Producto de romperme la cabeza para lograr un mayor entendimiento sobre cómo funciona un sistema de archivos. Antes que nada debo excusarme por mi escasa actividad en el blog, últimamente mi tiempo se escapa desarrollando Web (PHP+MySQL+HTML+CSS+JavaScript), mi trabajo en seguridad, estudiando Java para tratar de certificar este año, y lo que me resulta más interesante: incursionando en virtualización de servidores utilizando KVM sobre host CentOS. Varias veces pensé en escribir sobre virtualización en KVM, pero el tema es tan amplio que no sé cómo encararlo. Tal vez debería empezar con mini-artículos sobre temas puntuales, como este que escribo, pero me falta tiempo. Prometo más adelante abordar el tema...


Breve intro

Para experimentar con virtualización tomé la decisión de utilizar CentOS, clon a nivel binario de RedHat, y utilizar KVM en favor de Xen. Para las máquinas virtuales decidí utilizar volúmenes lógicos de LVM como discos virtuales en lugar de archivos de imagen. No voy a explicar en este artículo las ventajas de utilizar volúmenes lógicos así que vamos directo a lo técnico...


Necesito un backup de mi máquina virtual

(Si necesitas un tutorial de LVM no lo vas a encontrar en este artículo, Google it!, hay muchos buenos tutoriales dando vueltas: 1, 2, 3)

Necesito hacer un backup de una máquina virtual cuyo disco es un volumen lógico y no un archivo de imagen. Además necesito mantener la máquina virtual en ejecución. Es decir, hacer un backup online. No hay problema! Una de las ventajas de LVM es que permite tomar snapshots de volúmenes lógicos, una especie de "instantánea" del contenido del volumen.

En la figura superior vemos un esquema de ejemplo de un disco. Una de las particiones se marca como tipo 8e y queda disponible como espacio para volúmenes lógicos. Supongamos que el volumen lógico asignado a la vm se llama "vm01" y pertenece al grupo de volúmenes lógicos "vm_group". Para crear un snapshot del volumen lógico utilizamos "lvcreate":

lvcreate --size 16G --snapshot --name vm01-snapshot /dev/vm_group/vm01

Donde --size indica el tamaño máximo del volumen, --name indica el nombre del volumen lógico correspondiente al snapshot y el último parámetro indica la ruta al dispositivo. El resultado es una copia del volumen en un instante determinado.


Listo el backup!

Eso es todo, aunque... Si el guest posee una base de datos, se debe hacer un lock para que cualquier aplicación en ejecución no escriba en tablas, y además se debe hacer un flush para escribir a disco todos los registros que se encuentran en memoria. Esto es necesario para que la base de datos quede en un estado consistente al momento de tomar el snapshot. Se puede hacer utilizando la herramienta ShellSQL (en CentOS se debe agregar el repositorio RPMforge para instalarla)


Que hago con el backup?

Una vez que tenemos la snapshot seguramente queremos moverla a un servidor de backup. Para esto necesitamos montar la imagen y copiarla al servidor de backup utilizando ftp (quise decir sftp, ver este artículo) o inclusive scp.

En Linux no es posible montar una partición LVM (tipo 8e), sólo es posible montar volúmenes lógicos. Esto es fácil si el volumen lógico posee un sistema de archivos como ext2, ext3 o NTFS. Los problemas surgen cuando el volumen lógico (partición lógica) contiene varias particiones en lugar de un sistema de archivos (las cosas se vuelven algo confusas).

¿Por qué un volumen lógico tendría varias particiones? Simple, si es utilizado por una máquina virtual tiene al menos una partición, ya que todo sistema operativo necesita al menos una o varias particiones para funcionar (/boot, /, /var, /home, etc.)

Si tratamos de montar un volumen lógico particionado obtendremos el siguiente resultado:

hfs: unable to find HFS+ superblock

Significa que mount no encuentra ningún sistema de archivos, ya que para encontrar un sistema de archivos habrá que buscarlo en la tabla de particiones. Recordemos que lo que para el host (el volumen lógico) es una partición, para el guest virtual es un dispositivo. El resultado es que tenemos particiones dentro de una partición lógica :S

Montar una partición que se encuentra dentro de un volumen lógico

Gracias a esta guía pude lograr lo que necesitaba. Primero veamos qué particiones contiene el volumen lógico correspondiente al snapshot:

[root@myserver ~]# fdisk -l -u /dev/vm_group/vm01-snapshot

Disk /dev/vm_group/vm01-snapshot: 10.4 GB, 10485760000 bytes
255 heads, 63 sectors/track, 1274 cylinders, total 20480000 sectors
Units = sectors of 1 * 512 = 512 bytes

             Device Boot      Start         End      Blocks   Id  System
/dev/vm_group/vm01-snapshot1   *          63    20450744    10225341    7  HPFS/NTFS

Se observa que el volumen lógico posee una única partición NTFS. El parámetro -u se utiliza para que las unidades sean en sectores y no en cilindros. Esta partición se puede montar si le indicamos a mount que el volumen lógico vm01 es un loopback device y le pasamos un offset (medido en bytes) al comienzo de la partición deseada.
El sistema de archivos NTFS comienza en el sector 63 (se observa en la captura anterior) y cada sector posee 512 bytes. Por lo tanto el offset es 32256.
Con los siguientes parámetros logramos montar la partición deseada:

[root@myserver ~]# mount -o loop,offset=32256 -t ntfs /dev/vm_group/vm01-snapshot /media/vm01-snapshot/
The disk contains an unclean file system (0, 0).
The file system wasn't safely closed on Windows. Fixing.

Voila! Tenemos la partición montada!

[root@myserver ~]# la /media/vm01-snapshot/
total 1310609
drwxrwxrwx 1 root root      8192 Feb 16 07:39 Archivos de programa
-rwxrwxrwx 1 root root         0 Feb  3 11:32 AUTOEXEC.BAT
-rwxrwxrwx 1 root root      4952 Aug 24  2001 Bootfont.bin
-rwxrwxrwx 1 root root       211 Feb  3 11:29 boot.ini
-rwxrwxrwx 1 root root         0 Feb  3 11:32 CONFIG.SYS
drwxrwxrwx 1 root root      4096 Feb  3 11:37 Documents and Settings
-rwxrwxrwx 1 root root 536399872 Mar 30 12:46 hiberfil.sys
-rwxrwxrwx 1 root root         0 Feb  3 11:32 IO.SYS
-rwxrwxrwx 1 root root         0 Feb  3 11:32 MSDOS.SYS
drwxrwxrwx 1 root root         0 Feb 16 07:37 MSOCache
-rwxrwxrwx 1 root root     47564 Aug  3  2004 NTDETECT.COM
-rwxrwxrwx 1 root root    250640 Aug  3  2004 ntldr
-rwxrwxrwx 1 root root 805306368 Mar 30 12:46 pagefile.sys
drwxrwxrwx 1 root root      4096 Feb  3 11:36 System Volume Information
drwxrwxrwx 1 root root     28672 Feb 16 14:48 WINDOWS

Teniendo acceso a la partición podemos copiar el backup del disco donde deseamos (usando scp o sftp).

Espero que les sirva!

Teclado loco en Ubuntu

Escribo este post porque perdí toda la mañana del domingo renegando con esto y tal vez a alguien le sirva la solución:

El día anterior necesitaba trabajar en mi notebook y tuve la idea de usar los periféricos de la PC (monitor, teclado y mouse) para estar más cómodo. Todo funcionó perfecto, salvo que tuve que ajustar un poco la frecuencia de refresco para que se adapte mejor al monitor de 17" de la PC.

El problema apareció hoy cuando quise volver a utilizar mi notebook sin los periféricos de la PC. Al iniciar gnome, luego de loguearme, el teclado funcionaba de manera extraña: la tecla 'u' escribía un '4'; la 'i' un '5'; la 'o' un '6'; etc. Pero la mitad izquierda del teclado funcionaba perfectamente.

Al darme cuenta que el teclado funcionaba perfectamente antes de iniciar gdm (ya que mi contraseña para ingresar funcionaba) comencé a investigar un poco la configuración de gnome. Encontré que en directorio:

~/.gconf/desktop/gnome/peripherals/keyboard/.../0/

Existía un archivo llamado:

%gconf.xml

El mismo (lamentablemente lo borré por lo que no tengo el contenido exacto) tenía una única línea significativa que indicaba que la tecla 'Block Num' estaba activada. He aquí el problema, mi notebook no posee teclado numérico, por lo tanto no tiene esa tecla. Lo que sucedía era que las teclas entre la 'n' y la 'p' funcionaban como teclado numérico.


La solución fácil

Borrar el archivo "%gconf.xml" y el reiniciar gdm. El teclado vuelve a la normalidad.

Automatización de transferencias por SFTP

Ante la necesidad de transferir archivos entre servidores de forma automatizada (sin intervención humana) recordé la excelente opción que otorga openSSH en su suite de herramientas: autenticación mediante clave pública/privada.
Dado que en un script es bastante feo lograr la interacción requerida por SFTP para autenticar un usuario (comportamiento default), contar con esta opción es extremadamente útil. Sí, no es imposible realizar la autenticación de forma interactiva, algo que está muy bien explicado en varias páginas e hice en un script de backup hace un par de años, pero es mucho más elegante usar la otra opción.

La idea de este artículo es explicar en pocos pasos cómo configurar tanto el cliente como el servidor SSH para utilizar autenticación de clave pública/privada. Además les mostraré cómo escribir un script que, utilizando esta autenticación, sirve para enviar archivos de forma automática.
Como si esto fuera poco (?!), también les mostraré como escribir un script que utilice autenticación interactiva, a través de la herramienta expect. Todo claro?, entonces "a darle átomos".


Generación del par de claves pública/privada

Como la autenticación será a través de estas claves, necesitaremos generar un par por cada usuario que utilicemos. La generación es muy simple, gracias a la herramienta ssh-keygen (si suena a generador de serials para crackear aplicaciones). Las claves se pueden generar en cualquier máquina, no necesariamente el servidor o el cliente. El comando a ejecutar es:

$ ssh-keygen -f id_rsa -t rsa

donde:

-f especifica el nombre del archivo. Se generan dos archivos, la clave privada con el nombre que pasamos en el parámetro, y la pública con el nombre concatenado a .pub
-t especifica el algoritmo que deriva las claves (puede ser RSA o DSA, lo más común es usar RSA, aunque DSA es más seguro).

Ejemplo:

$ ssh-keygen -f id_rsa -t rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
68:82:cb:67:8d:b1:4c:e1:3c:da:22:c0:c3:22:48:c2 demasiadovivo@192.168.1.1
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|.                |
|.E  .            |
|*  + . .         |
|=+. B o S        |
|+..* O           |
|. = B .          |
| . +             |
|                 |
+-----------------+

Cuando intentemos generar las claves, el programa preguntará si deseamos asignarle un passphrase para proteger la clave privada. En este caso hay que dar enter porque si asignamos una passphrase, cada vez que deseemos autenticar un cliente, tendremos que poner dicha passphrase a mano, para desbloquer la clave privada... esto no serviría a nuestros propósitos de utilizar un script automático...

Del par generado, utilizaremos la clave pública en el servidor (id_rsa.pub en el ejemplo) y la privada en el cliente (id_rsa).


Configuración del servidor SSH/SFTP

En el servidor lo primero que tenemos que hacer es habilitar las opciones que permiten la autenticación con clave pública/privada, es decir, editando el archivo /etc/ssh/sshd_config (o /etc/sshd_config en otras distros):

RSAAuthentication yes
PubkeyAuthentication yes

Luego debemos copiar la clave pública del cliente en el archivo de claves autorizadas para ese usuario /home/usuario/.ssh/authorized_keys:

cat id_rsa.pub >> /home/usuario/.ssh/authorized_keys

Conexión desde el cliente

En el cliente tenemos dos alternativas: pasar la clave privada como parámetro de la llamada sftp, o copiar la clave privada en /home/usuario/.ssh/. En el segundo caso, al intentar loguearnos en el servidor remoto, sftp utilizará por default la clave que encuentre en el directorio ssh del home, es decir, podemos ejecutar:

sftp <usuario>@<hostname>
por ej: sftp demasiadovivo@192.168.1.2

Si necesitamos pasar la clave por parámetro (algo en muchos casos necesario porque el usuario que ejecuta el script puede no tener home), debemos ejecutar el siguiente comando:

sftp -o "IdentityFile=<clave-privada>" <nombre-usuario>@<hostname>
por ej: sftp "IdentityFile=/datos/id_rsa" demasiadovivo@192.168.1.2

Me costó bastante encontrar la forma de armar este último comando, es necesario leer bien el manual de ssh_config =S


Automatizar copiado de archivos

Como les comenté, la razón por la cual necesitaba lo anterior es para automatizar el envío de archivos de un servidor a otro. Una vez que tenemos la configuración necesaria, en el servidor1 o servidor cliente del servidor2, podemos colocar el siguiente script:

#!/bin/bash

CMDFILE="sftp-commands"

echo "put <path-archivo>
bye" > $CMDFILE
sftp -o "IdentityFile=<clave-privada>" -b $CMDFILE <nombre-usuario>@<hostname>
rm $CMDFILE

Como pueden observar, el script es muy simple. Lo que hace es usar sftp en modo batch (-b $CMDFILE) para poder enviar los comandos de forma no-interactiva, ya que en el comportamiento default sftp espera recibir de la standar input los comandos a ejecutar en el servidor.
En resúmen, crea un archivo temporal cuyo nombre es sftp-commands, en el cual coloca los comandos a ejecutar (por ejemplo, el put de un archivo). Luego llama a sftp utilizando autenticación de clave pública/privada y el modo batch, donde le pasa el archivo recién creado como input. Finalmente borra el archivo temporal.


Automatización, opción 2

El segundo script que les quería mostrar es cómo hacer lo anterior, pero con autenticación interactiva, algo un poco más sucio, pero igualmente útil:

#!/usr/bin/expect

spawn sftp <usuario>@<hostname>
expect "password:"
sleep 3
send "<mi-contraseña>\r";
expect ">"
send "put <path-archivo>\r"
expect ">"
send "bye\r"

Como el script es interactivo, si bien no hace falta que ingresemos manualmente ningún comando, éste se verá en la standar output, así que cuando llamemos al script es necesario redirigir la salida a /dev/null. Por ejemplo:

$ ./sftp-command &>/dev/null

Referencias

- How can I automate an SFTP transfer between two servers?
- sftp Linux man page
- ssh_config Linux man page

Auditar logs de accesos de servidores ISA utilizando LogParser

La semana pasada me tocó auditar accesos a Internet para buscar visitas a sitios Web maliciosos o inadecuados y detectar desvíos de seguridad. Para llevar a cabo esta tarea tuve que filtrar los logs de un servidor ISA que se utiliza como proxy para obtener información útil de acuerdo a diferentes criterios de búsqueda.

En este artículo voy a proveer información sobre cómo obtener de forma rápida y precisa esta información utilizando herramientas de línea de comandos. Estas herramientas permiten redirigir la salida a archivos de texto, y realizar el trabajo de forma eficiente y automágica.


Definiciones preliminares

ISA Server: Gateway integrado de seguridad perimetral que permite proteger el entorno de TI frente a las amenazas de Internet, además de proporcionar a los usuarios un acceso remoto seguro a las aplicaciones y datos corporativos (Fuente: Microsoft).

LogParser: LogParser es una herramienta de línea de comandos que provee consultas universales a archivos de texto tales como archivos de logs, archivos XML y CSV y fuentes de datos del sistema operativo Windows tales como logs de eventos, registry, el sistema de archivos y Active Directory (Fuente: Microsoft).

Bash: Programa cuya función consiste en interpretar órdenes. Está basado en la shell de Unix y es compatible con POSIX. Fue escrito para el proyecto GNU y es el intérprete de comandos por defecto en la mayoría de las distribuciones de Linux (Fuente: Wikipedia).


Filtrado de logs

Los logs de acceso de los servidores ISA generalmente se encuentran en la carpeta:

C:\Program Files\Microsoft ISA Server\ISALogs

Para obtener información útil de estos logs utilizaremos la herramienta LogParser provista por Microsoft de forma gratuita. LogParser toma una expresión SQL como parámetro en la línea de comandos, y muestra como resultado las líneas que contienen coincidencias para la misma. Utilizando esta herramienta es posible filtrar los logs de los servidores ISA para obtener información útil de forma resumida.

Al ejecutar LogParser desde el menú de inicio se abre una consola en el directorio donde se instaló y muestra la ayuda:

Microsoft (R) Log Parser Version 2.2.10
Copyright (C) 2004 Microsoft Corporation. All rights reserved.

Usage: LogParser [-i:] [-o:] |
file:[?param1=value1+...]
[] []
[-q[:ON|OFF]] [-e:] [-iw[:ON|OFF]]
[-stats[:ON|OFF]] [-saveDefaults] [-queryInfo]

LogParser -c -i: -o:
[] []
[] [-multiSite[:ON|OFF]]
[-q[:ON|OFF]] [-e:] [-iw[:ON|OFF]]
[-stats[:ON|OFF]] [-queryInfo]

-i: : one of IISW3C, NCSA, IIS, IISODBC, BIN, IISMSID,
HTTPERR, URLSCAN, CSV, TSV, W3C, XML, EVT, ETW,
NETMON, REG, ADS, TEXTLINE, TEXTWORD, FS, COM (if
omitted, will guess from the FROM clause)
-o: : one of CSV, TSV, XML, DATAGRID, CHART, SYSLOG,
NEUROVIEW, NAT, W3C, IIS, SQL, TPL, NULL (if omitted,
will guess from the INTO clause)
-q[:ON|OFF] : quiet mode; default is OFF
-e: : max # of parse errors before aborting; default is -1
(ignore all)
-iw[:ON|OFF] : ignore warnings; default is OFF
-stats[:ON|OFF] : display statistics after executing query; default is
ON
-c : use built-in conversion query
-multiSite[:ON|OFF] : send BIN conversion output to multiple files
depending on the SiteID value; default is OFF
-saveDefaults : save specified options as default values
-restoreDefaults : restore factory defaults
-queryInfo : display query processing information (does not
execute the query)


Examples:
LogParser "SELECT date, REVERSEDNS(c-ip) AS Client, COUNT(*) FROM file.log
WHERE sc-status<>200 GROUP BY date, Client" -e:10
LogParser file:myQuery.sql?myInput=C:\temp\ex*.log+myOutput=results.csv
LogParser -c -i:BIN -o:W3C file1.log file2.log "ComputerName IS NOT NULL"

Help:
-h GRAMMAR : SQL Language Grammar
-h FUNCTIONS [ ] : Functions Syntax
-h EXAMPLES : Example queries and commands
-h -i: : Help on
-h -o: : Help on
-h -c : Conversion help


Ejemplos de consultas típicas

El servidor ISA guarda cada acceso en un registro, el cual tiene una cantidad fija de campos. Por ejemplo para cada pedido: c-ip contiene la ip que lo realizó; date contiene la fecha; time la hora; r-host el nombre del servidor al cual se accedió; etc. Cada registro es una línea y cada campo se separa con un tabulador, de acuerdo al formato W3C.
Los logs del servidor ISA que me tocó auditar comienzan con la siguiente cabecera, que declara la versión del servidor y los nombres de los campos:

#Software: Microsoft(R) Internet Security and Acceleration Server 2000
#Version: 1.0
#Date: 2011-02-06 00:00:02
#Fields: c-ip cs-username c-agent sc-authenticated date time s-svcname s-computername cs-referred r-host r-ip r-port time-taken cs-bytes sc-bytes cs-protocol cs-transport s-operation cs-uri cs-mime-type s-object-source sc-status s-cache-info rule#1 rule#2

Al utilizar LogParser para filtrar logs de un servidor ISA, se debe indicar que el formato de entrada es W3C, y que los campos se separan con tab. Luego de estos parámetros opcionales (tipo de entrada y separador) se indica la consulta SQL que se desea realizar.
El archivo de log se pasa como parámetro dentro de la consulta SQL, puede ser un archivo local o un share. Además se puede utilizar asterisco para leer de múltiples archivos de log.
Debido a que el nombre de archivo no puede contener espacios, se deben reemplazar los mismos con '\u0020'.
Los nombres de los campos de los registros se obtienen directamente desde el archivo de log (en la 3er línea del archivo que se encuentra comentada con numeral). Es posible redireccionar la salida a un archivo utilizando el caracter '>' o desde la consulta SQL utilizando la orden "INTO".


Ver todos los sitios visitados por la IP 192.168.1.100:

C:\Program Files\Log Parser 2.2>Logparser -i:W3C -separator:'tab' "SELECT DISTINCT r-host AS Site FROM C:\Program\u0020Files\Microsoft\u0020ISA\u0020Server\ISALogs\*.log WHERE c-ip='192.168.1.100'"

El identificador DISTINCT delante del campo r-host se utiliza para que no repita resultados.


Ver todas las IP que ingresaron a facebook:

C:\Program Files\Log Parser 2.2>Logparser -i:W3C -separator:'tab' "SELECT DISTINCT c-ip AS IP, r-host AS URL FROM \\logserver\ISALogs\*.log WHERE r-host LIKE '%facebook.com%'"


Ver la cantidad de visitas por sitio:

C:\Program Files\Log Parser 2.2>Logparser -i:W3C -separator:'tab' "SELECT COUNT(*) AS Hits, r-host AS Site FROM \\logserver\ISALogs\*.log GROUP BY Site ORDER BY Hits DESC" > hits.txt

La orden COUNT(*) en conjunto con GROUP BY suman la cuenta para cada valor distinto del campo r-host. La orden ORDER BY en conjunto con DESC se utilizan para ordenar el resultado de forma descendente.


Ver las visitas que realizó la IP 192.168.1.50 entre la 1:00 AM y 2:00 AM:

C:\Program Files\Log Parser 2.2>Logparser -i:W3C -rtp:-1 -separator:'tab' "SELECT time AS Time, cs-uri AS URI FROM C:\Program\u0020Files\Microsoft\u0020ISA\u0020Server\ISALogs\*.log WHERE c-ip='192.168.1.50' AND (TO_TIME(time) BETWEEN TIMESTAMP('01:00:00','hh:mm:ss') AND TIMESTAMP('02:00:00','hh:mm:ss'))" > filtered_log.txt

Por defecto, LogParser muestra la salida paginada. La opción -rtp:-1 se utiliza para evitar esto y poder redireccionar la salida.


Ver los clientes del Proxy:

C:\Program Files\Log Parser 2.2>Logparser -i:W3C -separator:'tab' "SELECT c-ip as Client INTO clients.csv FROM C:\Program\u0020Files\Microsoft\u0020ISA\u0020Server\ISALogs\*.log GROUP BY Client ORDER BY Client" -o:CSV

En este caso se exporta la salida como un archivo CSV directamente en la consulta utilizando la orden "INTO". La opción -o:CSV se utiliza para indicarle a LoggParser que la salida se exporta a un archivo CSV.


Filtrado de logs utilizando bash

Si se dispone de acceso a una consola bash, es posible realizar esta misma tarea utilizando herramientas libres como grep, sed, awk, sort, etc. Está fuera del alcance de este artículo explicar el funcionamiento de cada una de estas herramientas. A continuación se muestra un ejemplo práctico.


Ver todos los sitios visitados por la IP 192.168.1.100:

$ time grep '192.168.1.100' WEBEXTD20120101.log | awk –F"\t" '{print $10}' | sort | uniq

Con grep se buscan todos los registros que contienen la dirección IP 192.168.1.100. Luego se utiliza awk para extraer la décima columna (separadas por tab), que corresponde con el campo r-host. Finalmente se ordena el resultado y se eliminan los registros repetidos.
Se utiliza el comando time para medir el tiempo que tarda en realizar el trabajo. Tanto utilizando LogParser como bash scripts los tiempos de ejecución son bajos.

Usar o no usar Joomla

En las últimas semanas varias personas me consultaron sobre qué me parecía el uso de Joomla para montar páginas Web. Mi respuesta en todos los casos es "depende". Lo importante a la hora de decidir entre montar un Joomla o hacer un desarrollo de cero es ver cuáles son las ventajas y desventajas de hacer una u otra cosa. Todo varía dependiendo del tipo de página que deseemos, el público al que queremos llegar, la funcionalidad que necesitamos, el grupo que se va a encargar del desarrollo del site, el mantenimiento que le van a dar, el nivel de seguridad, y por supuesto, el presupuesto con el que contamos.
Vale destacar que tomo como base Joomla porque es el CMS (Content Management System) libre más conocido y utilizado, pero que lo dicho se puede utilizar para cualquier otro CMS conocido como drupal, Wordpress, PHP Nuke, etc.
Las recomendaciones que compartiré con ustedes se basan en la experiencia de usar Joomla y de tratar con varios proveedores de software (dolores de cabeza si los hay).
Veamos entonces cuáles son las preguntas que deben hacerse para decidir por un desarrollo de cero o partir de un CMS como Joomla.


Background: qué es un CMS?

Me parece correcto que, antes de ver los puntos mencionados, describa qué es un Content Management System. La mayoría de los que siguen este blog seguramente está recontra familiarizados con este tipo de programas, pero la idea de este artículo es llegar a un público general.

Entonces, qué es un CMS y en qué se diferencia a realizar un desarrollo de cero? un CMS, en la jerga web, es un programa que nos permite montar rápidamente una página a través de una interfaz Web que tiene las herramientas necesarias para administrar contenido (texto, imágenes, multimedia, etc), menús, secciones, usuarios y visualización. Básicamente tenemos una página prearmada y lo único que tenemos que hacer es agregar el contenido, elegir qué deseamos mostrar y cómo. Es un "construir página web for dummies", algo que cualquiera puede hacer.
La diferencia con un desarrollo es que en un CMS no necesitamos programar nada, solamente administrar el contenido desde la sección de administración. Claro que si necesitamos una funcionalidad que el CMS no provee, necesitaremos un programador para que la agregue, pero este trabajo es ínfimo comparado a realizar todo el site desde cero.
En el caso de joomla, es posible extenderlo fácilmente a través de módulos y existen decenas o tal vez cientos de módulos disponibles gracias a los aportes de la comunidad libre.


Con qué presupuesto contamos?

El factor más importante, es el presupuesto. Después de todo, lo que importa es el vil metal. El presupuesto influirá directamente para responder el resto de las preguntas que planteo.
Si el presupuesto es pequeño, deberían decantarse por Joomla casi sin pensarlo. Los beneficios que brinda son muchos frente a un desarrollo hecho a medida con poco dinero.
Si, en cambio, contamos con gran presupuesto, lo mejor es contratar a una empresa con gran experiencia en desarrollo Web y que cree un site desde cero. Esto nos dará ventajas tanto para elegir exactamente qué es lo que queremos, como para mostrar una imagen empresarial importante y asignarle al site la seguridad necesaria. Es decir, si tienen gran presupuesto, no hace falta que sigan leyendo =P
Por otra parte, contando con un presupuesto mediano, revisen el resto de las preguntas y a partir de ellas decidan qué hacer.


Cuál es la imagen que deseamos mostrar?

La segunda pregunta que tenemos que hacernos es "cuál es la apariencia que queremos?". Con esto me refiero al prestigio que quedemos que tenga la página. Es un punto clave para decidir si utilizar un CMS o no.
No es lo mismo mostrar una página que se desarrolló desde cero que mostrar un Joomla. Esto es básico para las empresas, sobre todo empresas medianas para arriba, donde la imagen es muy importante.
Si bien los Joomla son realmente flexibles en cuanto a modificar la visualización de la página, alguien que medianamente conoce del tema se da cuenta que la página está hecha con Joomla. Yo veo una página y casi al instante me doy cuenta de si es un Joomla o no. Y al entrar al site de una empresa hecho con Joomla, lo primero que pienso es "son unos ratas" (i.e. no quisieron gastar mucho, o no les importa el site), lo cual en el mundo de las apariencias (alias marketing), es malo.
Por ello, si necesitamos mostrar una imagen de empresa importante, no lo piensen, realicen un desarrollo de cero.


Joomla es seguro?

Este punto está muy ligado con el anterior. Hoy en día no se puede desestimar la seguridad de un site web publicado a internet, es una locura y falta de sentido común hacerlo. Entonces, siendo tan importante el tema seguridad, pondrían un Joomla?
En este punto Joomla tiene puntos a favor y en contra. El gran punto a favor es que tiene una gran comunidad detrás revisando y corrigiendo errores continuamente y enviando los updates a los usuarios. Tener actualizaciones constantes es algo que casi nunca tenemos con un desarrollo a medida porque en general una empresa de software crea el site, lo pone online, lo cobra y listo, no existe soporte posterior.
El problema grave son los módulos desarrollados por terceros que en general no tienen soporte, abriendo una brecha de seguridad importante. La otra gran desventaja es que donde encuentran un agujero en Joomla o en uno de sus módulos, explotan todos los sites. Esto es, descubren un agujero y se publica en la web, y a partir de allí cualquiera puede explotar nuestro site (en conjunto con los otros cientos de sites hechos en Joomla). Esto nos abre a atacantes no dedicados, es decir, gente que no estuvo intentando hackear nuestro site de forma exclusiva, sino cualquier persona que vea que tenemos un Joomla.
Incluso cuando sale un agujero en Joomla, muchos deportivamente salen a buscar sites hechos con este CMS para hackear tantos como pueda, sin importarle realmente hackear nuestro site por alguna razón. Una búsqueda en google con el parámetro inurl:option=com_content nos traerá todos los sites hechos en Joomla que no cambiaron sus URLs.

Entonces, es seguro usar Joomla? si lo mantenemos actualizado, no usamos módulos de terceros sin soporte y lo configuramos correctamente, si. Incluso diría que es más seguro usar Joomla que un desarrollo a medida sin soporte, o un desarrollo a medida realizado por una empresa que no entiende o no le importa la seguridad (me he topado con tantos...).
A pesar de esto, si la seguridad es muy importante y deseamos que nos hackeen lo menos posible (nunca estaremos libres de la posibilidad de hackeo, eso tenganlo presente), mi recomendación es un site desarrollado de cero teniendo en cuenta las recomendaciones básicas de seguridad.
Si por otra parte deciden utilizar Joomla, lean el checklist de seguridad provisto por la misma comunidad: Security Checklist.


Qué funcionalidad necesitamos?

Otro punto importante es la funcionalidad. Joomla es bastante flexible, amigable y muy extensible, algo que nos permite tener alta funcionalidad. En un desarrollo de cero lograr la funcionalidad que tiene Joomla les costará mucho dinero y probablemente muchas peleas con los desarrolladores por no entender los requerimientos. Obviamente que hay ciertas cosas que están estructuradas de una manera (como la administración de contenidos) que si no les gusta deberán ser modificadas por un desarrollador.
La mayoría de los sites, desarrollados de cero, que contienen una sección de administración, que he visto, son una patada en los huevos. Administrar una página a través de ellos es una tortura, y un Joomla nos habría salvado de tanto sufrimiento.

En resumen, si funcionalidad es lo que buscan, mi recomendación es Joomla, a menos que tengan el tiempo, dinero, dedicación y paciencia necesarias para tratar con un equipo que desarrolle todo de cero.


Qué experiencia tiene la empresa que hará el desarrollo?

Si el presupuesto es mediano o bajo, probablemente deban contratar una empresa de acorde a esto. Es entonces cuando deberían preguntarse: confío lo suficiente en "tal empresa" como para que haga este desarrollo desde cero?
Si están en duda, pongan un Joomla! o bien sigan buscando desarrolladores hasta encontrar uno que parezca cumplir los requerimientos.


Queremos que el site se vea actualizado?

Lo primero que vemos al entrar en un site es su diseño visual, y es lo que importa para mostrar que mantenemos el site actualizado. Es muy importante renovar cada cierto tiempo la visualización para darle frescura y no aburrir.
Joomla, al igual que todos los CMSs importantes, posee un sistema de templates a través del cual es simple renovar la visualización, algo que no he visto en la mayoría de los desarrollos a medida. Además existen muchos templates gratis para descargar de Internet.
Este punto se puede ligar directamente con el de imagen empresarial que plantié anteriormente, pero trato de mostrarlo más abstracto. Tal vez tenga un site que deseo mantener actualizado visualmente, pero que no necesita mostrar una imagen de empresa tan importante. Igualmente este es el punto que menos influirá en la decisión, aunque si es para tener en cuenta. Deben saber que con Joomla será fácil mantener una visualización actualizada, mientras que con un desarrollo a medida deberán pedirlo explícitamente y probablemente aumente el presupuesto.


Conclusión?

Tal vez les dejé más interrogantes que respuestas, pero espero haber cumplido con informarlos lo suficiente como para poder tomar una decisión razonable.
En resumen, si poseen el suficiente dinero, hagan un desarrollo a medida. Lo mismo si esperan que no los hackeen en conjunto con otros 1000 sites, o si desean brindar una cierta imagen. En el resto de los casos, piensenlo bien, probablemente Joomla cumpla perfectamente sus necesidades.

Espero que ustedes puedan darme aportes sobre qué les parece el uso de Joomla en ámbitos empresariales, y tal vez agregar algunas preguntas más a la lista =)

Lo más leído en 2010

Otro año se va a la mierda y me pareció interesante hacer un repaso a los artículos más leídos durante el mismo.
Para el blog fue un buen año porque se incrementó un montón la cantidad de visitantes, y obtuvo más aportes de emilio que ayudaron a variar los temas tratados.
Estos últimos 2 o 3 meses, debido a distintas ocupaciones y falta de inspiración, no se publicaron tantos artículos, pero igualmente el contenido fue muy bueno. Siempre buscamos publicar información que no se encuentre fácilmente en español, e incluso información completa y experiencias que no se encuentra ni siquiera en inglés.
Espero que les haya gustado el contenido de este año y que encontraran respuestas a sus problemas informáticos en él. En el 2011 seguiremos publicando información que encontremos interesantes, y experiencias que tengamos en el trabajo diario.
Los dejo entonces con el top 10 de lo más leído durante el año:

1. Cracking passwords Windows y Active Directory. En este artículo se presentó información completa de cómo crackear passwords Windows (incluyendo diferentes herramientas), en conjunto con la explicación de cómo se almacenan los passwords en este sistema operativo y en Active Directory, y el background de por qué el sistema utilizado es tan débil.

2. Tips Slackware 13.1. Slackware es una de las distribuciones más difíciles de configurar y utilizar, pero también es una de las mejores. Por ello vale la pena probarla y Emi nos da en este artículo los tips para comenzar, explicando cómo instalarla y configurarla correctamente.

3. Monitoreo de red: OSSIM Review Parte I (OSSIM, Snort y OSSEC). Cuando escribí esta serie de artículos no imaginé que se volverían tan populares. OSSIM es una excelente distribución que incluye las herramientas necesarias ya configradas e integradas para que el monitoreo de red sea una tarea sencilla. En este artículo se introducen 3 de las herramientas más importantes del sistema, OSSIM, Snort y OSSEC.

4. El arte de la inyección blind (MySQL). Uno de los artículos que más me gustó escribir. En él se presenta la explicación de cómo realizar ataques de inyección SQL blind, donde el atacante sólo puede distinguir entre consultas true y false, a través de lo cual puede obtener todos los datos almacenados en las tablas.

5. Crear máquina virtual en CentOS usando Xen. Este data de mediados del año pasado y sigue en el top de los más leídos. Aquí describí los pasos que tuve que realizar para armar máquinas virtuales en un entorno donde se utiliza Xen.

6. Cómo crear un corrector ortográfico. Otro que data del año pasado y que sigue siendo muy leído. Cuando uno se pregunta ¿cómo se escribirá un corrector ortográfico? nunca se imagina lo simple que es, y en este artículo se demuestra a través de mini programas en java y python.

7. Rompiendo a lo grande: XSS avanzado. Data de fines del año pasado, donde se mostraron diferentes técnicas para realizar ataques XSS. En éste en particular, se muestran ataques avanzados y muestran el peligro de esta vulnerabilidad.

8. Monitoreo de red: OSSIM Review Parte II (Nagios, Nessus, OpenVAS, Osiris). Segunda parte del review de OSSIM, donde se introdujeron las herramientas Nagios, Nessus, OpenVAS y Osiris.

9. Monitoreo de red: OSSIM Review Parte III (Ntop, NFSen, Pads, P0f, Tcptrack, Arpwatch, OSC-NG). Tercera y última parte del review de OSSIM, donde se describieron las herramientas Ntop, NFSen, Pads, P0f, Tcptrack, Arpwatch y OCS-NG.

10. Combatiendo el Cross Site Scripting. El último puesto es para otro artículo de año pasado, de la serie XSS. En este se mostraron los mecanismos de defensa que se pueden utilizar para evitar el XSS, visto desde un posible cliente, y desde la programación.

Bueno, ese fue el top de este año. Como verán, algunos artículos que estuvieron en el top 10 del año pasado, están nuevamente en este, algo que me da la pauta de que la información resultó muy útil =)

Pasen un buen fin de año, y arranquen con todo el 2011!!!

236 troyanos en el disco C:\

Recientemente tuve que reparar un Windows XP infectado con un bonito virus polimórfico (W32.Sality). Este virus infecta los archivos ejecutables en discos locales, removibles y shares de smb. Además crea una botnet P2P y, lo mejor de todo, deshabilita todo software de seguridad instalado (léase antivirus). Esto último que parece tan peligroso en realidad es una debilidad, ya que lo pone en evidencia y permite detectar fácilmente que el sistema está infectado (un virus indetectable es mucho más peligroso ya que puede controlar un sistema durante mucho tiempo).

En el sitio de Symantec se puede leer una descripción completa del mismo. Aparentemente es un virus antiguo ya que se originó en Rusia (que novedad jeje) por el 2003. Se infecta reemplazando el código en el punto de entrada de los ejecutables para redirigir al código polimórfico, que se encripta y se adiciona en la última sección de los archivos.

Como comenté anteriormente, la forma de detectarlo fue fácil: desapareció el ícono del antivirus (en este caso ClamWin) de la barra de tareas de Windows XP y era imposible tratar de iniciarlo. Luego de escanear los discos utilizando clamav (desde un Linux instalado en otra partición, aunque podría ser también desde un livecd) se detectaron una gran cantidad de infecciones en archivos .exe.

Para remover el virus sin acudir a simple pero tediosa "formateada/reinstalada" utilicé una herramienta de AVG hecha a medida para este caso. Aunque previamente tuve que reparar la registry ya que Windows era incapaz de arrancar en modo a prueba de fallos a causa del virus.

Luego de desinfectar completamente el sistema utilizando la herramienta de AVG (tardó unas tres horas aproximadamente) el mismo volvió a funcionar correctamente, sin rastros del virus.


Ahora, que tiene que ver todo esto con el título del artículo?

Luego de escanear el sistema con clamav pasé un tiempo investigando el virus y la forma de removerlo. En un foro, no recuerdo cual, encontré un link al sitio www.virustotal.com.



Este sitio me pareció de lo más útil y original. Te deja subir un archivo infectado, lo escanea con una variedad de antivirus y te muestra el resultado. En ese momento me sirvió para confirmar el tipo de virus que tenía infectado, pero luego sentí curiosidad por probar este sitio un poco más. Para esto me puse a buscar virus y ver resultados:



Luego me dí cuenta que también es posible enviar una URL, por lo que me puse a buscar sitios maliciosos (de scam o malware) y ver que resultados tenía. Fue cuando me encontré con este espectacular sitio de malware:



Este sitio primero muestra un alert diciendo algo como "Se ha detectado actividad sospechosa en su sistema y a continuación será escaneado en busca de virus" Jaaa! es muy bueno. Luego se abre una imitación, muy bien lograda, del explorador de archivos de Windows con una barra de progreso del escaneo, el cual detecta 236 troyanos en el disco C:

Menuda infección jeje. Luego de este simulacro se redirige a la descarga de un archivo ejecutable y el resto se imaginarán.

De esta forma se puede ver un sitio de malware en acción, realmente brillante, sobretodo teniendo en cuenta que me apareció en la segunda página de la búsqueda en Google de la palabra "keygen". Esta clase de sitios pueden engañar a una gran cantidad de usuario de Windows, por eso no sorprende la cantidad y el tamaño de las botnets.

Procedí a escanear este sitio con VIRUS TOTAL el cual me mostró el siguiente resultado:



Me pareció raro que no todas las herramientas lo detectaran como sitio de malware. También me pareció raro que Google Safebrowsing lo detecte como sitio de malware pero aparezca en la segunda página de la búsqueda de la palabra "keygen" en Google Search... Cuestiones de Google.

En definitiva, VIRUS TOTAL, una excelente herramienta para tener a mano para analizar archivos sospechosos y sitios de scam.

Para finalizar les dejo unas recomendaciones:

• Mantengan su software antivirus actualizado (todos los días)


• Eviten visitar sitios sospechosos/desconocidos


• Tengan cuidado dónde hacen clic, siempre revisen las direcciones de los links que aparecen en la barras de estado de los browsers


• Mucho más cuidado con las descargas y archivos adjuntos


• Escaneen absolutamente todo lo que descarguen antes de abrir/ejecutar, por más tedioso que sea es preferible esto antes que enfrentarse a la pérdida de datos

Saludos y feliz 2011!!!

P.D.: Espero que el título del artículo resulte tan "vendedor" como el sitio de malware desde donde lo obtuve!

Protecciones contra buffer overflows en la práctica

Hace tiempo que deseo aprender a realizar ataques buffer overflow, pero por falta de tiempo (y a veces por no sentarme decidido a hacerlo) fue quedando relegado en la lista de cosas a aprender. Con aprender me refiero a realizar los ataques en la práctica, la teoría ya la conozco desde hace años! Pueden encontrar un par de artículos que escribí el año pasado sobre esto: Buffer overflow, un asesino en serie y Evitando que un programa explote, técnicas para detectar buffer overflows.
En fin, la cosa es que probando ejemplos del excelente libro "Gray Hat Hacking" y del tutorial Smashing The Stack For Fun And Profit me encontré con varias trabas. No solo tenía que entender lo que estaba tratando de hacer, sino entender el por qué ni siquiera copiando y pegando los ejemplos andaban!
Fue así que investigando encontré varias protecciones que el compilador GCC y el kernel colocan en los programas y me pareció interesante comentarlas.


Arquitectura 64 bits

El primer obstáculo que encuentra un atacante que intenta realizar un bof es la arquitectura. La arquitectura de 64bits agregó varias funcionalidades que le permiten al sistema operativo protegerse mejor. Principalmente las mejoras en cuanto a seguridad son:

- Bit No eXecution (NX), conocido como eXecute Disabled (XD) en Intel, o Enhanced Virus Protection en AMD. Este bit permite marcar las páginas como no ejecutables, con lo cual el sistema operativo ahora puede utilizar la arquitectura para setear páginas de memoria que contienen datos como no ejecutables, evitando así la ejecución de código inyectado en el stack o en el heap debido a un overflow.
La idea de evitar la ejecución en áreas de datos viene desde hace tiempo, pero al no tener soporte en la arquitectura x86 (que sólo permitía marcar una página como readonly/execute con el mismo bit) debía emularse por software. Un ejemplo de ello es el proyecto PaX.

El mapeo de qué secciones son ejecutables se pueden setear en el formato binario ELF. Allí el compilador coloca los headers del programa e indica a través de permisos RWE qué secciones son ejecutables.
Pueden ver los headers de cualquier programa con los comandos objdump o readelf. Por ejemplo, pueden utilizar readelf de la siguiente forma:

$ readelf -l programa

Para marcar que el stack es no ejecutable, se incorporó el header GNU_STACK, el cual es revisado por el loader para setear los permisos correctos. Si este header tiene los flags RW, la pila no tiene ejecución.
Este header lo incorpora GCC desde la versión 4.3 y por default cuando compilamos un programa veremos que el stack no tiene ejecución.
Como existen programas antiguos o que requieren especialmente ejecución en el stack, es posible marcar el stack como ejecutable. Si cuando compilamos un programa agregamos el argumento "-z execstack", el header GNU_STACK indicará los permisos RWE, incorporando así la ejecución.
También es posible habilitar la ejecución del stack utilizando el programa execstack. Con el parámetro "-s" indicamos que el programa tiene stack ejecutable y con "-c" eliminamos la ejecución.
Algo a tener en cuenta es que si no existe el header GNU_STACK, el loader asume que el programa necesita ejecución en el stack, esto se debe al deseo de proveer compatibilidad con programas viejos.

- Mayor espacio de randomización de direcciones (ASLR). En la arquitectura de 32 bits sólo se podían utilizar 8 bits para para la randomización de la dirección virtuales (teóricamente eran 20, pero por limitaciones en el SO, sólo quedaban 8), mientras que en la nueva arquitectura de 64 es posible utilizar 28 (teóricamente 36).
Esto complica aún más el tipo de ataques "return to libc", los cuales ya eran complejos al utilizar ASLR. Con arquitecturas de 32 bits era factible averiguar por fuerza bruta en qué direcciones se cargaban las librerías debido a la utilización de sólo 8 bits.


ASLR

En el artículo que escribí el año pasado les hablé sobre ASLR y de qué trata. En la sección anterior les comenté que en la arquitectura de 64bits se mejoró considerablemente esta randomización. Como dije, en la arquitectura de 32bits también existe esta protección y el kernel de linux la incorporó a partir de la versión 2.6.12 por default. Si quieren deshabilitar esta funcionalidad, simplemente ejecuten:

echo "0" > /proc/sys/kernel/randomize_va_space

Stack Smashting Protection

Esta técnica también la expliqué en el artículo de protección contra bof. En la práctica GCC utiliza el llamado canario para detectar cuándo ocurrió un overflow que pudo sobreescribir la dirección de retorno. Esto se hace incorporando un valor conocido (canario) entre la dirección de retorno y las variables locales de la función. De esta forma, si ocurre un overflow en alguna de las variables locales, deberá sobreescribir el canario antes de poder sobreescribir la dir de retorno. Este cambio en el canario será detectado por la función de protección y terminará el programa.
Por default en muchas distribuciones (por ejemplo debian) GCC viene configurado para incorporar este canario en los programas que compile, pero en caso de no hacerlo, el programador puede utilizar el parámetro "-fstack-protector" para agregarlo. Si no se desea utilizar y sabemos que el compilador lo agregaría por default, se puede utilizar el parámetro "-fno-stack-protector".


Buffer & Format String Vulnerability

Cuando se describe los bof hay algo que salta a la vista. El problema surge por no checkear cuántos datos se van a copiar en una dada variable de tamaño fijo, lo cual permite copiar por ejemplo 500 bytes en un arreglo de 300. Si las funciones que hacen las asignaciones comprobaran los tamaños, estaríamos a salvo. Existen alternativas seguras para funciones de la librería libc que sí comprueban los tamaños de buffers, así que por qué no usarlas?
En GCC existe una funcionalidad para fortificar el código, la cual se activa con el flag "-D_FORTIFY_SOURCE=2". Este flag le indica a GCC que checkee en tiempo de compilación los tamaños de los buffers y cambie llamadas a funciones que no limitan el tamaño de los buffers con funciones que si lo hagan. También hace que GCC agregue checkeos en tiempo de ejecución para los tamaños de los buffers y las regiones de memoria.
Algo a tener en cuenta con este flag es que sólo se puede utilizar con el parámetro "-O2", es decir, utilizando optimización de código.

Un ataque que no describí en los artículos sobre buffer overflows es el de Format String Attack. Este ataque se aprovecha de las funciones que utilizan formato, como printf, fprintf, sprintf y snprintf. La vulnerabilidad aparece cuando no se proveen tantos parámetros como se especifica en el formato (ej: printf("%s=%s", "mapeo")), o cuando se le permite al usuario ingresar el string de formato (ej: printf(argv[1]), y desde consola ejecutar ./programa "ataque %s %s"). Las funciones de formato intentan leer de la pila tantos parámetros como los especificados en el string de formato, así que si no se asigna la cantidad de parámetros correcta, podríamos leer datos de memoria arbitraria, o escribir en ella (utilizando %n), y, en ocasiones, lograr root!
En fin, si bien es fácil de evitar, el tema es bastante interesante, así que si quieren, pueden leer el paper Format String Attacks de Tim Newsham.
A lo que quería llegar con todo esto, es que la opción D_FORTIFY_SOURCE también evita ataques que escribiendo en la memoria, gracias al formateador %n, permitirían ejecutar código. Lo que hace simplemente el compilador es bloquear todos los format strings que contengan "%n".

Si la distribución de linux que utilizan tiene configurado GCC para usar D_FORTIFY_SOURCE por default, pueden desactivarlo usando el parámetro "-D_FORTIFY_SOURCE=0".


Referencias

- Buffer overflows on linux-x86-64
- x86-64 buffer overflow exploits and the borrowed code chunks exploitation technique
- ::: GCC PROTECTIONS :::
- Ubuntu Wiki CompilerFlags
- debian Wiki Hardening
- The GNU Stack Quickstart
- Gray Hat Hacking - The Ethical Hacker's Handbook
- Format String Attacks

Usando Google como Web proxy

Hoy estaba leyendo este interesante artículo que trata la ciberguerra que se ha desatado entre los defensores y detractores de Wikileaks (yo soy un defensor de Wikileaks), y por esas cosas de Internet terminé en cualquier otra cosa.
Estaba husmeando los posts en twitter del nefasto th3j35t3r, un payaso que se dedica a provocar ataques DDoS contra diferentes sitios, la mayoría musulmanes, y que además se encargó de efectuar estos ataques contra Wikileaks ("for attempting to endager the lives of our troops, 'other assets' & foreign relatios").

La cuestion es que se me ocurrió visitar uno de estos sitios musulmanes """terroristas""" por
simple curiosidad, y me encotré con estos chirimbolos indescifrables del idioma árabe. Entonces decidí utilizar Google translate para pasar la página al idioma inglés y entender algo.
El sitio en sí era bastante aburrido, pero lo interesante fue que al ver la URL en la barra de direcciones de Firefox, se me ocurrió utilzar a Google como Web proxy (para aquellos que no sepan que es un proxy, pueden buscar en Wikipedia y leer mi artículo anterior).

Además de ocultar nuestro trasero, un proxy nos permite acceder a sitios no permitidos por la política de nuestro dominio (en mi caso, un proxy que filtra, entre otros sitios, facebook, twitter, etc).
Esto nos muestra una vez más cómo se puede abusar de un servicio tan inofensivo como Google translate.

Veamos cómo funciona paso a paso:

Primero veamos con qué IP salimos a Internet visitando el sitio ip-adress.com:



Se observa que salimos con una dirección 200.x.x.x perteneciente a nuestra organización. Ahora ingresamos a Google translate y colocamos la URL en el cuadro de traducción:



Google translate nos muestra la misma página pero dentro de un frame. Observamos que la dirección es ahora 74.125.114.80 que corresponde con un servidor de Google:



Para finalizar, probamos ingresar a un sitio no permitido, como es linkedin en mi caso:



La página no se ve correctamente, pero al menos se puede acceder ;)

De esta forma logramos utilizar a Google como Web proxy.

Espero que lo disfruten!

Instalar IOS en switches Cisco desde ROM Monitor

Otra vez les traigo el resultado de un reto Cisco, en este caso, cómo instalar un IOS en un switch de la serie 2900 (seguramente funcione en otros modelos) desde el ROM Monitor. En un post anterior les mostré cómo actualizar el IOS de estos equipos, pero contando con un IOS base desde el cual hacer el trabajo. En este artículo les voy a comentar cómo instalar un IOS en un switch que no tiene ningún IOS, ya sea porque el que tenía se corrompió, o bien porque (como yo) se mandaron una cagada al intentar hacer el cambio y rompieron el IOS que tenían antes de instalar uno nuevo =P

En mi caso, el problema fue que borré el IOS que tenía instalado para hacer lugar para el que quería instalar (gracias Cisco por poner unos pocos megas mugrosos de flash!!!), y luego copié un IOS sin descomprimir (behh).

Si no tenemos un IOS en buen estado para bootear, el switch queda en el bootstrap (Cisco lo llama ROM Monitor), el cual provee una funcionalidad muy (MUY!) básica. Este bootstrap se ejecuta siempre que encendemos el switch, piensen en él como el grub de los switchs. Cuando existe un IOS booteable, el bootstrap lo carga, pero sino, quedamos atascados en este pequeño programa.

Entonces, qué hacemos?

Es claro que si no tenemos IOS, necesitamos cargar uno nuevo. Versiones modernas del ROM Monitor permiten utilizar tftp para la transferencia, o bien cargar automáticamente un IOS por tftp si dejamos pulsado el botón MODE, como vimos en el caso de los AP 1240 .

En los switchs más antiguos (como los 2900), no contamos con ninguna de las dos posibilidades, así que tenemos una sola alternativa... copiar el IOS a través de la consola usando el protocolo XMODEM.

Los pasos que describo a continuación los tomé de Recovering Catalyst Fixed Configuration Switches from a Corrupted or Missing Image, modificándolos para utilizar minicom además de Hyper Terminal.

1. Apenas iniciamos el switch, ejecutar flash_init y load_helper.

2. Ver si tenemos espacio en la flash para la nueva imagen con "dir flash:". Si no tenemos lugar, borrar la imagen vieja:

delete flash:c2950−i6q4l2−mz.121−11.EA1a.bin

3. Copiar la nueva imagen utilizando xmodem. Para ello, en el switch ejecutamos el comando:

copy xmodem: flash:c2950−i6q4l2−mz.121−13.EA1.bin

Si estamos utilizando minicom para la conexión con el switch (ver Acceder dispositivos Cisco desde GNU/Linux con minicom), el siguiente paso es ejecutar:

- CTRL-A y luego Z, para entrar a las opciones de minicom

- S para elegir la opción "send file"

- elegimos la opción xmodem, con lo cual se nos abrirá un navegador de archivos. En este navegador buscamos el archivo con la imagen del IOS, lo seleccionamos con la barra espaciadora y le damos Okay y luego enter.

Si, en cambio, utilizan Hyper Terminal:

- Vayan al menu "Transfer -> Send File"

- escriban el path a la nueva imagen, o bien busquenla utilizando la opción "Browse".

- elijan la opción Xmodem en la sección "Protocol" de la ventana y aprieten "Send" para enviar el archivo.

4. Cuando se complete la transferencia, ya tendremos la nueva imagen en la flash. Tengan en cuenta que la transferencia por xmodem es asquerosamente lenta!!! tardé cerca de una hora para copiar 1MB! así que tengan paciencia jeje

Lo que hacemos a continuación es bootear la nueva imagen utilizando el comando:

boot flash:c2950−i6q4l2−mz.121−13.EA1.bin

Ahora si, hemos convertido un switch pisa papeles (el clásico stoned) en uno utilizable. Espero que les sirva!