A brief and real malware story

Esta historia (real por sobre todas las cosas), sucedió hace ya algo mas de un año e involucro a un webserver productivo de una ONG Argentina a la cual en la empresa en la que trabajo, le hacemos mantenimiento de sistemas e infraestructura. El desencadenante del siguiente procedimiento, fue un llamado telefónico por parte del cliente, manifestando que el webserver eventualmente andaba lento, y había que determinar cual era el origen de este problema. Luego de atender los tickets previamente asignados me puse a trabajar en el caso, logueandome de manera remota al equipo (que se encontraba en un conocido datacenter de Argentina), y tras ejecutar las herramientas típicas de detección de problemas de performance y/o observación (vmstat para inspeccionar la memoria virtual, iostat para inspeccionar el IO y mpstat para inspeccionar CPU) comienzo a revisar los logs del sistema operativo, un CentOS 6.2 x86_64, en este caso. Y tras ejecutar el comando dmesg (encargado de loguear los mensajes del booteo, como así también del kernel) me encuentro con lo siguiente:

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: 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

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.

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.

RHEL/CentOS: SELinux for Apache virtualhosts

Sabemos que los virtualhost se utilizan para poder alojar en un mismo webserver, con una única IP, varios sitios webs. Muchos administradores de hosting que implementan esto sobre Red Hat o CentOS, al momento de la instalación desactivan SELinux para evitar conflictos de acceso a los distintos recursos del sistema.

SELinux por trabaja en dos modos, Enforcing, en el cual por default todo se deniega, y se permite acceso únicamente a lo que se explicitamente permitido, y Permissive, en lo cual por default todo se deniega, pero en vez de bloquear el acceso, simplemente notifica esto en los logs (/var/log/messages y /var/log/audit/audit.log) y debe ser utilizado solamente para testing.

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. 

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.