VMWare Server: Adding a VNC server without web console.

Una de las plataformas de virtualización con mayor aceptación en el mercado actualmente es VMWare, en sus versiones enterprise tales como ESX/ESXi o en su versión gratuita (apta para PoC, o uso hogareño), VMWare Server. Quienes me conocen, saben que no tengo demasiada simpatía con este producto, lo cual hace que mi interés en el mismo no sea mas allá que instalarlo en algún server, crear máquinas virtuales y hacer alguna que otra tarea administrativa con el, pero no más.

Esta terrorífica historia que hoy les traigo, me sucedió hace algunos meses en un servidor productivo, que utilizaba VMWare Server. El equipo se había caído, y por algún motivo extraño la interfaz web no levantaba. Siguiendo la Ley de Murphy: "Si algo puede salir mal, lo hará..."
Una de las VM's no había levantado correctamente y no tenía forma alguna de conectarme a ella para ver por qué no booteaba el sistema operativo, así que buscando en Google, encontré esto:

Linux x86: Adjacent Memory Overflows

Durante los días 18 y 19 de Octubre de 2012, tuve el placer de viajar y presentarme como disertante a la 8.8 Security Conference en la hermosa ciudad de Santiago de Chile.

Durante mi conferencia sobre "Buffer Overflow for fun and pr0fit", luego de la larga y aburrida introducción teórica hice algunas demostraciones prácticas de explotación de binarios, bypasseo de protecciones y "adjacent memory corruption explotation" en la cual esta última falló, quizá por la presión de hacerlo en vivo, nervios o lo que sea, falló. Entonces me gustaría a través de este post hacer un repaso de este último tópico que me hubiera encantado haberlo compartido en vivo durante mi charla.

Linux/KVM: Growing filesystem on a LVM based virtual disk.

Cuando se utiliza virtualización, las capacidades de flexibilización del storage son enormes, es por ello existen diferentes formas de manejar el almacenamiento utilizando KVM como hypervisor.
Una de ellas es utilizar filedisks, con los cuales, cada uno de ellos emula un disco físico en la VM y los filesystems son armados ahí mismo.
Otra forma es mediante LVM dedicando uno o varios LV a uso exclusivo de la VM.
Esta última forma, optimiza el I/O debido a que se evita pasar por una capa intermedia de abstracción: "un archivo", a fin de escribir los bloques de datos a disco. De esta manera las operaciones de I/O son manejadas directamente por el Device Mapper (LVM), y se evita caer en capas de abstracción intermediarias.
Este caso era sencillo, un servidor de correos en CentOS 5.6, bajo "Zimbra", el cual tiene un disco basado en un LV (vdb1), que monta en /opt, directorio utilizado por Zimbra para mantener todos sus datos, el cual se había quedado sin espacio.

POSIX: System-V Executable and Linkeable Format (ELF) and the Linux ABI

ELF son las siglas en inglés de Executable and Linkeable Format, y es el formato de archivo utilizado por los file objects (.o), binarios, librerías y coredumps en Linux y en Unix en general.
El principio de todo proceso, define al mismo como un archivo en un dispositivo de almacenamiento, que una vez compilado y al ser ejecutado, es cargado en memoria para que el scheduler (mediante el sistema operativo), le asigne tiempo de CPU y recursos a fin de poder ejecutar las rutinas definidas en el.
Este archivo, ya convertido en binario, se encuentra escrito en algunos de los cientos lenguajes de programación que existen actualmente, por ejemplo ANSI C o Fortran. Cuando fue compilado, el compilador en un momento determinado ejecuto el linker, y definió en un header todas aquellas librerías que el programa necesita para poder ejecutarse y que estás les provean aquellas funciones y procedimientos que utilice.
Un binario, puede ser compilado de dos formas, una es estática y la otra dinámica. Compilar un binario de manera estática (parámetro -Bstatic en gcc(2)), significa que se incluirán en el mismo binario todas aquellas librerías que el programa requiera. Por su parte, la principal idea de las librerías compartidas, es tener una sola copia de las mismas instaladas en el sistema operativo y que todo aquel programa que las necesite, haga uso de ellas, y las cargue en memoria para ejecución, en segmentos que pueden ser mapeados de manera privada para el proceso, o compartido entre varios procesos/threads.

Los procesos en Unix, nacen de alguna de las variantes de la syscall fork(2). fork(2), bifurca el proceso padre en una nueva imagen del proceso (una nueva entrada en la estructura proc_t), y mediante exec(2) desplaza esta imagen para crear el mapeo y la estructuras en memoria para el nuevo proceso ejecutado.
Una vez realizado el exec del proceso, y si este está compilado de manera dinámica, en invocado el runtime linker, en este caso ld.so.1,

POSIX: INT_MAX, INT_MIN and SIGFPE

En sistemas operativos modernos, los límites de direccionamiento de memoria y cantidad de procesos/threads está estipulada de dos formas: la primera acorde al hardware específico con que cuenta el equipo, y la segunda, mediante configuración específica del sistema operativo.

A modo de ejemplo, y para dejar las cosas más en claro, vamos a hablar un poco sobre los límites de los procesos: Cada proceso en el sistema operativo ocupa un slot en una estructura de datos denominada kernel process table. Esta tabla contiene toda la información necesaria que el kernel mantiene a fin de poder manejar los procesos, schedulear las distintas tareas (acorde a sus prioridades) y estados de los mismos. Cuando el OS bootea, el kernel inicializa una estructura de datos denominada process_cache, donde comenzará a direccionar la estructura de procesos que luego serán empleada por el kernel y el userspace. Esta tabla es una lista doblemente enlazada con dos punteros, uno a su elemento anterior y otro a su elemento posterior, la cual tiene una capacidad máxima que se define acorde a la cantidad de memoria física instalada en el equipo. El sistema operativo, para esto asigna la cantidad de memoria instalada a una variable MAX_MAXUSERS (que no tiene nada que ver con el número máximo de usuarios que el sistema soporta), que luego será utilizada por dos variables más del propio kernel max_nprocs y maxuprc. max_nprocs define el número máximo de procesos del sistema operativo, y maxuprc determina el número máximo de procesos que usuarios no privilegiados (que no sean root), puedan crear y ocupar slots en la kernel process table. Y basándose en el valor de MAX_MAXUSERS, poder definir el tamaño en memoria de cada segmento del proceso (región .text, .stack, .heap, .bss, etc.).

CentOS / Red Hat: Making a persistent KVM network bridge

Hoy en día cuando la virtualización se a convertido en una tecnología de facto en la mayoría de los datacenter existen numerosas soluciones compitiendo en el mercado. En mi caso si me dan a elegir entre las distintas soluciones de pago para Linux, elijo una gratuita (y libre), KVM.
KVM (Kernel-based Virtual Machine), es una solución que nos provee full virtualización, haciendo uso de qemu como hypervisor, la cual se encuentra integrada dentro del propio kernel de Linux de manera modular, mediante el módulo del kernel kvm.ko. Esto nos provee cierta compatibilidad y performance que la ponen prácticamente a la par de otras soluciones de virtualización.
Una de las tareas comunes al crear una nueva maquina virtual, es integrar a esta con la red existente, ya que la virtualización nos provee la posibilidad de hostear múltiples servidores en un solo equipo físico.

La configuración en RHEL o CentOS es muy sencilla, para ello debemos crear un bridge, quien será el responsable de interactuar con la red física. Para hacer esto, al momento de booteo y cuando los scripts SYSV de RC configuran la red (mediante el servicio network), el bridge es configurado utilizando brctl, y la configuración leída de aquellos archivos de interfaces los cuales son definidos como bridge.
En nuestro ejemplo tendremos dos Una NIC física (eth0), en la cual crearemos el bridge y lo configuraremos acorde a los paramétros de networking que necesitemos asignarle al servidor.

Performance analysis: A study case (bottleneck)

Como una manera de seguir ilustrando el post anterior "Performance analysis: Understanding the vmstat comand output", vamos a realizar un rápido análisis de un bottleneck producido en un equipo debido a la baja lentitud de la controladora de disco. Si bien en este caso el equipo no es más que una laptop, ejemplifica bien lo que es el estudio de performance que puede aplicarse a una gran variedad de equipos. Como en esta serie de post, solo hemos tratado con vmstat(1), utilizaremos tal herramienta para realizar el análisis.

Síntomas
El equipo, en momentos en los que se sometía a alta carga de trabajo de I/O se volvía extremadamente lento, dejando de responder por momentos, no habiendo otra solución que apagarlo, o esperar un buen rato. Si bien es entendible que el mismo se "quede" sin memoria y swapee, esto no se hacía de una manera tan agresiva, por lo cual se analizara la existencia de otro problema.

Descripción del equipo
El equipo es una laptop HP 420, con una CPU Pentium(R) Dual-Core CPU T4500 @ 2.30GHz, en cuanto a su memoría RAM se encuentra conectado un módulo DDR2 de 2 Gb. además cuenta con un disco rígido Western Digital WDC WD5000BPVT-00HXZT3 utilizando la interfaz SATAII. El sistema operativo que corre en el mismo es Linux (Fedora 16), x86_64, utilizando el kernel 3.3.1-5.fc16.x86_64. Sin entrar en más detalles vemos que dice lspci(1), sobre los dispositivos conectados al mismo:

Performance analysis: Understanding the vmstat command output

Todo sysadmin que se digne de tal, tiene la capacidad de optimizar sus equipos para soportar las distintas situaciones de carga a las que se puede ver sometido o resolver bottlenecks que puedan llegar a producirse. Existen varias situaciones que pueden sobrecargar un equipo, y siempre es útil comprender cuando se producen y los procedimientos para remediarlas.
La performance es un área difícil de comprender, pero fundamental a la hora de administrar sistemas.
Durante este post vamos a intentar comprender la salida de vmstat(8), un comando disponible en la mayoría de los sistemas Unix, en nuestro caso vamos a enfocarnos en Linux, y analizaremos algunas situaciones las cuales pueden llevar a una sobrecarga de performance.
Existen numerosas herramientas para analizar esto, pero muchas de ellas dan su punto de partida en vmstat(8), para luego enfocar en herramientas más específicas como iostat(8), mpstat(1), o sar(1). Para un mayor entendimiento de performance y las herramientas utilizadas les recomiendo el blog de Brendan Gregg, o también leer el libro "Solaris™ Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris" por Richard McDougall, Jim Mauro y Brendan Gregg

Installing Fedora 16 in non GPT partition table.

En mi laptop del trabajo, por una cuestión de practicidad utilizo Fedora 16, es una distro que me resulta bastante cómoda, debido a que diariamente suelo trabajar con Linux, especificamente con RHEL y CentOS.

Como muchos saben las nuevas features de RHEL, previamente se incorporan a Fedora para que la comunidad las pruebe primero, y fue así, como por ejemplo, comencé a familiarizarme con Systemd (el remplazo de LSB Scripts). 

Una de las características que incorpora Fedora 16, y no Fedora 15, es que por default utiliza GPT (GUID Partition Table), en lugar de MBR (Master Boot Record) como se venía haciendo en las arquitecturas x86 y 86_64. GPT forma parte del estándar EFI (Extensible Fimreware Interface) y es propuesto por Intel para reemplazar PC BIOS. Entre las ventajas prácticas que incorpora GPT es que limita el tamaño máximo de la partición 9.4 zettabytes, mientras que este límite para MBR es de 2.4 terabytes y la cantidad de particiones definidas en en el disco. 

OpenBSD: Enabling serial console for KVM/libvirt utilization

Tengo un OpenBSD 5.0 con el que estoy realizando una serie de pruebas en una máquina virtual sobre KVM en CentOS 6. KVM en conjunto con libvirt, provee una serie de herramientas para administrar el host virtualizado, una de ella es virt-manager, una herramienta escrita utilizando GTK que obviamente necesita tener X ejecutándose. La otra es virsh, una CLI para administración de hosts virtuales.

Virsh tiene la interesante opción de poder attachear una consola virtual, la cual previamente debe estar configurada en el sistema operativo guest. Esto es importante para poder realizar con la VM todo el trabajo que no podemos hacer de manera remota utilizando SSH y así tener que evitar abrir virt-manager cada vez que tengamos que agregar algún parámetro al booteo, por ejemplo.

Cabe destacar que esta configuración no solo aplica a hosts virtuales, sino también a hosts físicos que tienen la posibilidad o se conectan mediante consola serie. Los pasos para realizar esto son bastante sencillos:

Unix: Stateful firewalls vs. Non-Stateful firewalls

Hace unos días tuve una interesante discusión en Twitter sobre las ventajas de utilizar como firewall Packet Filter contra Netfilter (IPTables). Cabe destacar que tengo mas conocimientos de PF que de IPTables, por lo cual conozco más las ventajas prácticas del primero que del último.

En teoría de firewalls, encontramos los denominados stateful firewalls, son firewalls que actúan en layer 3 del modelo OSI/ISO (network) donde su punto fuerte es el poder de inspeccionar estados, y saber si los mismos corresponden a una conexión ya existente o no. Esto es posible lograrlo en Linux mediante connectrion tracking utilizando los módulos conntrack, y  así mantener un record de los estados existentes en el sistema operativo.

Tanto Packet Filter como IP Filter utilizan una estructura denominada tabla de estados (o status table), para mantener dicha información. Si un paquete IP ingresa al firewall, se va a buscar mediante una previa inspección del header si el mismo forma parte de una conexión ya existente, y si esto es cierto no se van a inspeccionar reglas de filtrado, sino que el paquete va a pasar directamente. Si un paquete llega por primera vez al firewall, el mismo si matchea con alguna regla, entonces va a crear una entrada en la tabla de estados del firewall, y ya, mientras la conexión siga viva no va a pasar por dicha inspección de reglas.

Linux: Determine if a program is using TCPWrappers

TCP Wrappers es un sistema de ACL's basado en hosts y redes, multiplataforma; Que permite o deniega la acceso a un demonio en un sistema a ciertos hosts o redes, Su configuración se realiza editando los archivos /etc/hosts.allow y /etc/hosts.deny mediante el host o las redes que queremos permitir o denegar y las claves ALL, LOCAL, UNKNOW, KNOW y PARANOID.


Que un demonio utilice TCP Wrappers significa que el mismo fue compilado y linkeado contra libwrap.so y podemos determinarlo simplemente haciendo uso de ldd. Por ejemplo, podemos ver que SSH utiliza TCP Wrappers:

# ldd $(which sshd) | grep libwrap
 libwrap.so.0 => /lib64/libwrap.so.0 (0x00002aae2628b000)

Linux: Enabling LVM devices from live CD.

Hoy en mi trabajo tuve que resizear un volumen group donde se encontraba como LV el root filesystem (/) de un equipo con CentOS 5.4. Esta tarea no puede ser realizada en caliente, ya que consistía en reducir de 1.5 Tb. a 300 Gb. el volumen lógico del root filesystem (LVRoot) para después reducir el Volumen Group (VolGroup00).

Uno de los problemas con que es común encontrarse es que toda la metadata de LVM esta disponible, por ejemplo utilizando pvdisplay, vgdisplay y lvdisplay; Pero en /dev no tenemos las entradas correspondientes al device mapper creadas (/dev/mapper/VolGroup00 y /dev/VolGroup00).

Linux: Connection tracking with FTP and iptables

Uno de los problemas más comunes con que se puede encontrar un sysadmin utilizando iptables es a la hora de hacer el deployment de un servidor FTP (como por ejemplo vsftpd o proftpd) estando detrás de un  NAT. El cliente se podrá conectar al servidor, pero este no logrará realizar ninguna operación en el (como listar, o transferir archivos).

Según los distintos RFC que definen al protocolo FTP, este por regla general utiliza dos puertos, el TCP/20 para datos y el TCP/21 para control; Aunque esto no siempre es así y es lo que veremos en este post.
Para evitar el problema mencionado anteriormente, podemos decir que FTP trabaja en dos modos: el modo activo y el modo pasivo.

Linux: Recovering a corrupt superblock

Una de las estructuras más básicas del filesystem son los bloques. Estos pueden ser utilizados para dos propósitos: El primero de ellos guardar datos, el segundo almacenar metadata que referencien a dichos datos.

En otras palabras, la metadata, describe la estructura del filesystem como así también sus atributos.
Existe un bloque muy importante en los filesystem denominado superblock, este bloque contiene toda la información referida a dicho sistema de archivos, y es en quien se fija el sistema a la hora de montarlo. Por ejemplo el contendrá la cantidad de inodos, los grupos de bloques, el tipo del filesystem, el estado, el tamaño, etc. Su ubicación varía dependiendo del tamaño de bloque usado, por default este tamaño es de 1024 bytes, pero esto varía entre 2048, o 4096.

Red Hat / CentOS: Running Apache with SELinux on a nonstandard port

En el post anterior explique los fundamentos para hacer correr SELinux con enforcing en virtualhosts fuera del directorio /var/www.
Ahora supongamos que queremos ejecutar también utilizando SELinux en enforcing Apache en un puerto diferente al 80, por ejemplo el 1080. Sabemos que utilizando un puerto menor a 1023 debemos utilizar root para poder iniciar httpd.

Lo primero que debemos hacer es cambiar la configuración del puerto en el archivo /etc/httpd/conf/httpd.conf.

Linux: Identifying a physical network interface card

Hay momentos en los que es necesario identificar físicamente una interfaz de red, por ejemplo, cuando se debe cablear, o armar un bonding.
Esto suele ser una tarea bastante compleja cuando trabajamos con una cantidad grande de servidores y distintos modelos de ellos, ya que los dispositivos pueden ser nombrados de manera distinta, y donde en un servidor es eth0, puede ser eth1. Existe una herramienta muy útil en Linux, que se denomina ethtool. 

Linux: The kernel SysRq and the SAK key.

Muchos usuarios de Linux, no conocen la existencia de dos combinaciones de teclas que suelen resultar muy útiles a la hora de que un equipo no responda, o al momento de loguearse en uno.

SysRq key:
Cuando hablamos de kernel SysRq key, nos referimos a una combinación de teclas especial, la cual va a realizar que un equipo paniqueado, ocrasheado, sea capaz de responder, y poder rebootear de una manera un poco más suave que dandole el botonazo.

Para poder hacer uso y utilización de esta combinación de teclas, debemos previamente tener soporte a esta en la configuración del kernel, para ello buscamos, en el archivo config de este el siguiente string, que representa un valor booleano:

#: cat /boot/config-2.6.40.4-5.fc15.x86_64 | grep -i sysrq
CONFIG_MAGIC_SYSRQ=y

En este caso se encuentra soportado, en caso contrario, habría que recompilar el kernel, dandole soporte en dicha directiva de configuración. 

RHEL/CentOS: Examining and building the initial ramdisk

Como muchos de ustedes seguramente sabrán, al bootear un equipo, es necesario tener cargados ciertos módulos como el de la controladora de disco (ATA/SATA/SCSI), filesystems, manejo de memoria, entre otros, para de esta forma poder realizar la secuencia normal de booteo e inicio del sistema.

Pero, aquí entramos en el clásico problema "The Chicken/Egg problem". ¿Como el OS monta la rootfs, si aún no tiene cargado los módulos?. Es que para ello existe, mis queridos amigos el initial RAM disk, o mejor conocido como initrd. Un filesystem temporal, utilizado por el kernel, que al momento del booteo es cargado en /dev/ram0. El kernel utilizará en un principio dicho RAM disk, como rootfs, hasta que el kernel monte el rootfs real, y lo posicione como tal mediante la syscall pivot_root.
Esto se realiza, escribiendo el número del real rootfs en el archivo /proc/sys/kernel/real-root-dev.  Un ejemplo de ello podría ser:

# echo 0x301 >/proc/sys/kernel/real-root-dev

Ustedes sabrán que dentro del kernel, los módulos pueden ser compilados, built-in, osea construidos dentro de este o en forma de modulo, siendo cargados a medida que se necesitan.
Construir un kernel, con todos los drivers necesarios buil-in, daría lugar a un kernel pesado, y mas lento. Es por ello que estos drivers esenciales, que deben cargarse en algún momento del booteo del equipo, deben ser incluido en el initial RAM disk.

Linux: Connect to a remote domain0 using virsh and SSH

Es bastante común tener VM's hosteadas en un host remoto, al cual podemos acceder mediante Internet, o conectándonos a la LAN local. Sin importar cual fuera el caso, en Linux principalmente existen dos plataformas medianamente "nativas" de virtualización (ambas proveen full virtualización), ellas son Xen, que no es otra cosa que un parche al kernel de Linux, y KVM, que esta integrada como módulo dentro del mismo y para conectarnos, disponemos siempre de un protocolo excelente como es SSH.
Existe una interfaz de administración por linea de comandos denominada virsh, a la cual le indicamos el hypervisor al que queremos conectar y el protocolo a utilizar.