Optimizar base de datos MySQL

MySQL es el motor de base de datos por defecto de numerosas aplicaciones, entre ellas Bacula. Y como otros muchos motores de bases de datos, tiene su parte buena y su parte mala. La parte buena es la flexibilidad y potencia que nos ofrece. La parte mala es que en aplicaciones muy dinámicas, hablando de datos, MySQL tiende a fragmentar las tablas y por lo tanto, espacio en disco ocupado y rapidez de acceso a datos aumentan. Aunque este post lo relacionamos directamente con Bacula, este pequeño truco sirve para cualquier otras aplicación que emplee MySQL. Lo que vamos a explicar aquí, es como optimizar un poco las tablas, es decir, que tras realizar muchas escrituras y borrados y también updates, hacer que la estructura de la tabla vuelva a ser la óptima. Existen dos formas, la primera es la clausulo OPTIMIZE de mysql, y la segunda, un pequeño script, que aparece en la documentación de bacula. Ambas estrategias van a realizar algo parecido, desfragmentar la tabla, repararla y ordenar los índices. Vamos a ver cómo funcionan.
  • OPTIMIZE
    Es una clausula de MySQL y sobre tablas MyISAM da muy buenos resultados. Por lo tanto, para aplicarlo a bacula, simplemente tendremos que ejecutar dicha clausula sobre todas las tablas, una a una. 
    mysql> OPTIMIZE LOCAL TABLE bacula.BaseFiles;
    +------------------+----------+----------+----------+
    | Table            | Op       | Msg_type | Msg_text |
    +------------------+----------+----------+----------+
    | bacula.BaseFiles | optimize | status   | OK       |
    +------------------+----------+----------+----------+
    1 row in set (0.00 sec)
    
    mysql> OPTIMIZE LOCAL TABLE bacula.CDImages;
    +-----------------+----------+----------+----------+
    | Table           | Op       | Msg_type | Msg_text |
    +-----------------+----------+----------+----------+
    | bacula.CDImages | optimize | status   | OK       |
    +-----------------+----------+----------+----------+
    1 row in set (0.00 sec)
    
    Según el grado de fragmentación que presente, el proceso puede llevar más o menos tiempo.
  • script
    Esta forma es algo más elaborada y requiere escribir un poco de código, pero el resultado es mucho más óptimo y queda más logrado. Realizamos el siguiente script,
    #!/bin/bash
    
    inMB=$(du -ms $DIR | awk '{print $1}')
    echo "DB Bacula size: $inMB MB"
    echo "Optimize MySQL Database (I): dump"
    mysqldump -f -uroot -p --opt bacula > /tmp/bacula.sql
    echo "Optimize MySQL Database (II): write"
    mysql -u root -p bacula < /tmp/bacula.sql
    echo "Delete security copy"
    rm -f /tmp/bacula.sql
    newInMB=$(du -ms $DIR | awk '{print $1}')
    echo "New DB Bacula size: $newInMB MB"
    RATIO=`echo "scale=2; ($inMB-$newInMB)/$inMB*100" | bc`
    echo "$RATIO % compress ratio"
    
    Antes de ejecutarlo, intentamos comprender un poco lo que hace, que no es más que realizar un dump de la base de datos bacula para luego volver a insertarla. Al insertarla, genera el schema y borra los datos actuales para volver a meterlos, sacando toda fragmentación y ordenando los índices.
    Un ejemplo de ejecución sería,
    DB Bacula size: 1577 MB
    Optimize MySQL Database (I): dump
    Optimize MySQL Database (II): write
    Delete security copy
    New DB Bacula size: 897 MB
    43.00% compress ratio
    
Cualquier de las dos opciones es buena, y es aconsejable según el uso que se haga de bacula ejecutarla cada 3 o 6 meses. Si el equipo realiza muchas copias de seguridad, ejecutarlo una vez al mes, tampoco sobra. Realmente, lo importante es el porcentaje de espacio que se le gana. En esta ejecución, fue de un 43%, efectivamente lo necesitaba. Si la mejora es de un 3%, obviamente, no ;-)
Leer más

Coloreando log's

Una de las partes más importantes de los sistemas GNU/Linux es fa facilidad que tiene este de saber todo lo que pasa en el sistema. Syslog está prácticamente integrado en todo el software que existe y por lo tanto saber algo de nuestro sistema es simplemente cuestión de ir a un log para verlo. De ahí la vital importancia de syslog/rsyslog y de la carpeta /var/log.
Sin embargo, fijo que a todos nos ha pasado, cuando tenemos que mirar muchas líneas de log puede resultar un poco monótono e incluso molesto no tener unos colores que te vayan indicando las palabras clave sobre las que deberías fijarte más. Puesto que los ficheros de log son texto plano, su contenido se puede listar de muchas formas: tail, cat, less, more, etc. pero ninguno de estos colorea la salida. Así que vamos a ver cómo conseguir una salida de colores para nuestro log.
Para empezar vamos a instalar ccze, un paquete que se encargará de dar color a nuestro contenido.
shell> apt-get install ccze
Tras su instalación ya tenemos listo el sistema de coloreado y podemos hacer lo siguiente para ver el log,
shell> ccze -A < /var/log/syslog
Puesto que esta forma de ver los log's puede no resultar 100% cómoda, vamos a crear una pequeña función en el alias de nuestro usuario que haga lo mismo, pero de forma más sencilla. Para hacerlo debemos editar el fichero ~/.bashrc y agregar las siguiente líneas al final del mismo.
log() {
   ccze -A < $1 | less -R
}
Ahora que ya tenemos la nueva función creada, le indicamos a nuestro usuario que vuelva a leer el contenido de dicho fichero, para que tenga la nueva función disponible,
shell> source ~/.bashrc
Y ya podemos hacerlo siguiente,
shell> log /var/log/syslog
May 24 13:58:02 se groupadd[922]: new group: name=postdrop, GID=106
May 24 14:00:16 se groupadd[128]: group added to /etc/group: name=scanner, GID=107
May 24 14:00:16 se groupadd[128]: group added to /etc/gshadow: name=scanner
May 24 14:00:16 se groupadd[128]: new group: name=scanner, GID=107
May 24 14:00:18 se groupadd[147]: group added to /etc/group: name=messagebus, GID=108
May 24 14:00:18 se groupadd[147]: group added to /etc/gshadow: name=messagebus
May 24 14:00:18 se groupadd[147]: new group: name=messagebus, GID=108
Lógicamente, en la función log yo empleo less, pero cada uno que emplee el paginador con el que más cómodo se sienta.
A mayores de colorear, el comando ccze tiene también alguna que otra ventaja, como puede ser la conversión automática de fechas en UnixTime a formato legible automáticamente. Este tipo de fechas nos las podemos encontrar en ficheros de log de Squid o de Zabbix.

La entrada Coloreando log's la puedes leer en Puppet Linux.
Leer más

Possible missing firmware

Estoy estrenando un nuevo equipo y tras la instalación de Debian Wheezy en este nuevo hardware me sale cada vez que actualizo temas del kernel el siguiente mensaje por consola,
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module r8169
No es que sea nada malo, pero sí resulta un poco molesto, así que mejor lo saco. Para ello, debo de instalar el paquete del firmware para la tarjeta realtek. Simplemente,
shell> apt-get install firmware-realtek
Y listo!

La entrada Possible missing firmware la puedes leer en Puppet Linux.
Leer más

Control de acceso SSH

Aunque ya lo comentamos alguna vez más, hoy vamos a ver otra forma diferente de controlar el acceso de usuarios a nuestro sistema mediante SSH. Si una cosa buena tiene GNU/Linux es que puedas hacer la misma acción de muchas formas diferentes. Hay que reconocer que lo que tiene de bueno, también lo tiene de malo. Pero en la diversidad está el divertimiento, así que manos a la obra.
Partimos de un sistema con el servidor SSH instalado en el que queremos impedir el acceso al usuario root desde SSH (puerto 22), para todos los equipos, exceptuando los de su red, desde los que sí podrá tener acceso. Para lograrlo, debemos editar el fichero /etc/pam.d/sshd y descomentamos o agregamos la siguiente línea,
account    required     pam_access.so
Con ella indicamos al sistema SSH que emplee el módulo pam_access para permitir el acceso. Una vez habilitado, sólo queda configurar dicho módulo. Para ello editamos el fichero /etc/security/access.conf y añadimos la configuración
#Denied ALL EXCEPT
- : root : ALL EXCEPT 192.168.1.
Una forma sencilla y elegante de lograrlo.

La entrada Control de acceso SSH la puedes leer en Puppet Linux.
Leer más

SSH sólo para túneles

Ya hablamos de cómo crear un túnel SSH y también cómo hacer un túnel SSH inverso. Estas dos opciones son muy interesantes, especialmente la primera, a la hora del trabajo diario, sin embargo puede darse el caso de que nos interese establecer un túnel SSH contra una máquina, por ejemplo, para acceder a una tercera, pero que no nos interese (por el motivos que sea) dejar una conexión SSH "abierta", es decir, una consola. Si no vamos a realizar ningún trabajo en esa máquina, sino que únicamente la vamos a emplear de puente, para qué tener una conexión establecida. Para evitar esta consola innecesaria, SSH permite establecer un túnel no interactivo. Para lograrlo, únicamente debemos de emplear la opción -N, que evita que se abra una conexión interactiva (una consola) y la opción -f, que hace que el cliente SSH pase a segundo plano. Luego únicamente debemos de crear el túnel como siempre.
shell> ssh -N -f -L 1025:remote-desktop:443 server-ssh

La entrada SSH sólo para túneles la puedes leer en Puppet Linux.
Leer más

mutt para envío de correo

mutt es un cliente de correo en consola para GNU/Linux. Es muy similar a mail, pero mucho más potente, ya que permite manejar todo un buzón remoto de correo, así como conectarse a servidores remotos para el envío de correos.
Hoy vamos a ver cómo configurar nuestro sistema para que envíe correos a través de una dirección de Gmail o de Google App Engine. Realmente mutt permite enviar correo empleando un servidor de correo local, por ejemplo un postfix en localhost, pero a algunos servidores eso tipo de envíos no les termina de gustar, sino que los mail's deben de ir desde un servidor "real". Es por ello que vamos a configurar mutt para que saque todos los correos a través de la cuenta de gmail que tengamos para tal efecto.
Para ello, lo primero es instalar mutt en el sistema,
shell> apt-get install mutt
Y a continuación configurar en la home del usuario que enviará los correos el ficheros de configuración de mutt, el .muttrc con el siguiente contenido,
set from = "YOUR_USER@gmail.com"
set realname = "YOUR NAME"
set smtp_url = "smtp://YOUR_USER@smtp.gmail.com:587/"
set smtp_pass = "YOUR_PASSWD"
Tras ello, simplemente al enviar un mail con mutt, éste automáticamente se conectará a los servidores de Google para efectuar a través de ellos el envío.
En caso de que tengáis una cuenta de Google App Engine y queráis hacer uso de esta técnica, bastará con introducir vuestro usuario completo "YOUR_USER@domain.com" en los lugares que corresponda, quedando la configuración final tal que así,
set from = "YOUR_USER@domain.com"
set realname = "YOUR NAME"
set smtp_url = "smtp://YOUR_USER@domain.com@smtp.gmail.com:587/"
set smtp_pass = "YOUR_PASSWD"

La entrada mutt para envío de correo la puedes leer en Puppet Linux.
Leer más

SSH, túnel inverso

Hace un tiempo hablamos en este blog sobre cómo crear un túnel SSH al conectarse a un servidor. Algo que nos puede ser de gran utilidad, especialmente cuando sólo tenemos acceso a un puerto SSH de un equipo en la red, pero sabemos que más allá hay más puertos accesibles.
Sin embargo, SSH permite más tipos de túneles, como puede ser el túnel inverso. Aunque éste es menos común en su uso, puede ser igual de interesante saber, cuando menos, que existe. El funcionamiento es justo el inverso del túnel SSH, es decir, lo que vamos es dar visibilidad de un puerto accesible localmente a un puerto en el servidor al que nos conectamos. Aunque puede que no tenga un interés masivo, el túnel inverso tiene sus utilidades.
La forma de establecerlo es,
shell> ssh -R 1025:localhost:80 server-ssh
Tras ello, desde el equipo server-ssh en el puerto 1025 estará accesible el mismo contenido que desde el equipo cliente de la conexión el 80, o lo que es lo mismo, exportamos el servidor web local al puerto 1025 remoto.
Al igual que con el túnel normal, en el túnel inverso podemos "enviar" un puerto de otro equipo,
shell> ssh -R 1025:win-server:3690 server-ssh
Donde el nombre win-server debe ser resuelto desde localhost, o bien emplear una IP directamente.

La entrada SSH, túnel inverso la puedes leer en Puppet Linux.
Leer más

Arquitectura del sistema

GNU/Linux tiene soporte para multitud de arquitecturas y aunque habitualmente se encuentra instalado sobre plataformas Intel, puede darse el caso de que tengáis sistemas Linux en otra arquitectura. En este caso, Debian suele ser la mejor, ya que su soporte a infinidad de arquitecturas es un ejemplo a seguir. Pero vamos a lo que realmente nos interesa, ¿cómo podemos saber la arquitectura del sistema que estamos ejecutando? Esta típica pregunta se suele hacer habitualmente al tratarse de sistemas de 32 o de 64 bit's, en caso de que queramos descargar un software específico. Como siempre, hay muchas formas de averiguar qué sistema tenemos instalado, así que vamos a ver algunas.
  • Sistema instalado
    shell> uname -a
    Linux null 3.2.0-4 #1 SMP PREEMPT Debian 3.2.41-2 i686 GNU/Linux
    
  • Arquitectura instalada
    shell> uname -m
    i686
    
  • Configuración del sistema
    shell> getconf LONG_BIT
    32
    
  • Microporcesador
    shell> lscpu | grep Architecture
    Architecture:          i686
    
En todo el ejemplo vemos que el sistema es de 32 bit's o i686, mientras que la salida para sistemas de 64 bit's sería,
shell> uname -m
x86_64
shell> getconf LONG_BIT
64
Y tú, ¿en qué arquitectura trabajas? Puedes dejarlo en comentarios.

La entrada Arquitectura del sistema la puedes leer en Puppet Linux.
Leer más

Gestión de trabajos en GNU/Linux

Uno de los temas más complicados de programar y de gestionar por cualquier sistema operativo es sin duda la cola de procesos en ejecución. Cómo repartir tiempo de CPU, cómo gestionar el paso de procesos de activo a espera de CPU o a espera de alguna entrada, etc. Este mismo proceso se puede llevar a cabo dentro del sistema GNU/Linux y es lo que se conoce como gestión de jobs. En el caso del sistema, un trabajo podemos hacer que quede detenido, en segundo plano o en plano de ejecución. Como veremos a continuación, no es lo mismo.


shell> sleep 10
Este comando ejecuta una parada de 10 segundo y al finalizarla termina. Si ahora, durante su ejecución presionamos Control+Z, el proceso quedará detenido.
shell> sleep 10
^Z
[1]+  Detenido                sleep 10
En este caso, que el proceso quede detenido significa que no va a terminar, quedará ahí indefinidamente, ya que no está pidiendo CPU para terminar. Para volver a activarlo, tendremos que volver acceder a él.
Justo el caso contrario es este,
shell> sleep 10 &
[2] 7017
donde gracias al comodín & final dejamos el proceso en segundo plano, pero ejecutándose. Cuando éste termine obtendremos su salida (en caso de que la tenga) y sino información de que ha terminado. Pasados 10 segundos, al presionar cualquier tecla sobre la consola, tendremos esta salida,
[2]-  Hecho                   sleep 10
Sin embargo, el primer proceso que dejamos en segundo plano quedó detenido y no sabemos nada de él. Para tener más información del mismo podemos emplear el comando jobs, que nos listará los procesos en segundo plano y su estado,
shell> jobs
[1]+  Detenido                sleep 10
[2]-  Ejecutando              sleep 10 &
Como vemos, el 2 está en ejecución y el 1 está detenido. El 2 terminará por si mismo, mientras que el primero lo podremos o bien matar,
shell> kill %1
[1]+  Terminado               sleep 10
O bien recuperarlo en la consola activa gracias al comando fg.
shell> fg %1
sleep 10

La entrada Gestión de trabajos en GNU/Linux la puedes leer en Puppet Linux.
Leer más

Locuras del calor, llevar SWAP a RAM


Este post es de esos que hay que escribir por aprender y por utilizar, pero que realmente puede que nunca llegue a tener una utilidad real. Vamos a ver cómo emplear parte de la memoria RAM para colocar nuestra memoria SWAP, es decir, utilizar la RAM para cuando no tengamos RAM.
Aunque puede parecer un sin sentido, en realidad siempre se le pueden encontrar buenos motivos para emplearlo. A mi ahora mismo se me ocurren,
  • Ver la versatilidad que GNU/Linux ofrece
  • Optimizar/minimizar el acceso a disco
  • Aprender cosas nuevas ;-)
Pero si tenemos que emplear caché es por que no tenemos más RAM, por lo que tenerla ahí ocupada no ayuda demasiado. Eso es cierto, pero el empleo de zRAM tiene la ventaja de que comprime los datos que emplea, por lo que 100Mb de caché pueden rendir como muchos más. A mayores tenemos la caché en memoria "rápida", por lo que incrementa el rendimiento del sistema y en equipos con mucha memoria y discos SSD, minimiza los accesos al mismo.
Pues una vez explicado la idea, vamos a ver cómo emplear zRAM. Para ello, tenemos que comprobar que nuestro sistema tiene soporte para ella,
shell> grep -i zram /boot/config-`uname -r`
CONFIG_ZRAM=m
# CONFIG_ZRAM_DEBUG is not set
En mi sistema zRAM está como un módulo del kernel, por lo que para usarlo debemos de cargar primero dicho módulo,
shell> modprobe zram
Una vez cargado tendremos un nuevo dispositivo, al cual tendremos que darle un tamaño. Es importante no pasarse, ya que este "disco" realmente no está comiendo la RAM, pero acordaros que luego trabaja con datos comprimidos. En mi caso voy a crear un dispositivo de 150Mb,
shell> echo $((150*1024*1024)) > /sys/block/zram0/disksize
Y a continuación, simplemente le indicamos a nuestro sistema que ese disco también forma parte de la SWAP.
shell> mkswap /dev/zram0
shell> swapon -p 10 /dev/zram0
En la segunda línea ejecutada montamos el disco como SWAP y le damos mayor prioridad que al resto de disco que tengamos configurado. Esto es necesario para que use esta partición virtual antes que la física, que es más lenta.
Si lo probáis ya contaréis qué tal la experiencia.

La entrada Locuras del calor, llevar SWAP a RAM lo puedes leer en Puppet Linux.
Leer más

SSH, limitar los intentos de login

Sobre configuraciones de seguridad y optimización del servidor SSH ya hablamos bastante, pero es cierto que le fichero de configuración del servicio (/etc/ssh/sshd_config) es muy extenso, por lo que siempre habrá parámetros nuevos que nos interese modificar que garanticen un poco más la seguridad. En este caso vamos a comentar 3 parámetros  que no se suelen mencionar muy a menudo, pero que pueden ser de interés.
  • LoginGraceTime
    Indica el número de segundos que la pantalla de login estará disponible para introducir el nombre de usuario y la contraseña. En caso de que en ese tiempo no se haya introducido nada, se cerrará automáticamente. Es una buena idea dejar este tiempo bajo, a 20 o 30 segundos, que es más que suficiente para que alguien pueda meter sus credenciales.
    Es importante tener este tiempo bien establecido, para así evitar que la pantalla de login quede ahí esperando credenciales por tiempo ilimitado y que alguien no autorizado pueda intentar acceder.
    LoginGraceTime 30
    
  • MaxAuthTries
    Indica el número de veces que un usuario puede equivocarse de contraseña y el sistema se la seguirá solicitando. Un número bueno de veces son 2 o 3, más ya no, ya que permitiría a un posible atacante reintentar un número de veces mayor obtener las credenciales.
    Es cierto que este número no impide para nada que el atacante vuelva a intentar loguearse, pero cuando menos le obliga a tener que volver a lanzar el comando de login (ssh -l user ip). Algunos bot's por la red dejarán de intentarlo, otros no.
    MaxAuthTries 2
    
  • MaxStartups
    Indica el número máximo de pantallas de login simultáneas que un usuario podrá tener en el mismo momento. No tiene nada que ver con el número de sesiones por usuario, sino con el número de sesiones de intento de login simultáneos que tendrá. 1 o 2 pantallas deberían de llegar, ya que así evitaríamos tener ataques por fuerza bruta con el mismo usuario.
    MaxStartups 2
    
Lógicamente todas las medidas de seguridad que se pongan en el servidor SSH no son efectivas si la contraseña no es segura. Así que ya sabéis, vuestros usuarios deben siempre tener una contraseña fuerte.

La entrada SSH, limitar los intentos de login la puedes leer en Puppet Linux.
Leer más

Debian Plymouth Boot Animation

Debian Wheezy ha salido recientemente a la luz y como era de esperar trae muchas e interesantes mejoras. Sin embargo, el sistema recién instalado sigue sin ser todo lo atractivo que pudiera ser. Hay que reconocer que los arranques de Windows y de Ubuntu (y derivadas) son mucho mejores. La animación gráfico durante el boot del sistema queda mucho más profesional que una consola en negro, pasando líneas. Es por ello, que con mi recién nueva instalación decidí ponerme a trabajar y conseguir un "Graphical Boot Animation". Hace años ya lo había logrado, pero realmente, conseguirlo era un arduo trabajo y casi había que recompilar el kernel, cosa a la que ahora no estaba dispuesto. Así que tocó hacer un poco de ingeniería inversa. ¿Qué paquete es el que ofrece el boot loader en Ubuntu? ¿Estará ese paquete disponible en Debian? Por suerte, la respuesta fue sencilla de encontrar. El paquete se llama plymouth. A la segunda pregunta, también obtuve una rápida respuesta,
shell> apt-cache search plymouth
plymouth - Graphical Boot Animation and Logger
plymouth-dev - Graphical Boot Animation and Logger (development)
plymouth-drm - Graphical Boot Animation and Logger (DRM)
plymouth-x11 - Graphical Boot Animation and Logger
plymouth-themes-all        - Themes metapackage
plymouth-themes-fade-in    - Fade-in theme
plymouth-themes-glow       - Glow theme
plymouth-themes-script     - Script theme
plymouth-themes-solar      - Solar theme
plymouth-themes-spinfinity - Spinfinity theme
plymouth-themes-spinner    - Spinner theme
Así que parece que ya tenía solución y por fin podría abandonar el inicio clásico que me acompañó tantos años.
Debian console boot
Así que vamos a ver cómo instalar plymounth en Debian Wheezy. Lo primero de todo, instalar el paquete y el tema con el que queramos arrancar. Yo personalmente opté por instalar el tema JOY, que ya viene incluido con el paquete, por lo que únicamente tuve que instalar el software base.
shell> apt-get install plymouth
A continuación debemos de darle soporte a nuestro GRUB para que soporte el boot loader de forma correcta. Para ello editamos el fichero de configuración /etc/default/grub y ponemos la resolución de arranque más óptima que queramos. En mi caso,
...
GRUB_GFXMODE=1024x768
...
Y también, bajo el mismo fichero, modificamos la variable GRUB_CMDLINE_LINUX_DEFAULT, dejándola tal que así,
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
Y finalmente ejecutamos
shell> update-grub2
Ahora que ya tenemos todo listo, sólo nos queda por indicarle a plymouth qué tema de todos los disponibles tiene que usar.
shell> plymouth-set-default-theme --list
details
fade-in
glow
joy
script
solar
spacefun
spinfinity
spinner
text
Para seleccionar el tema, simplemente
shell> plymouth-set-default-theme joy
Y finalmente actualizamos initramfs para que coja los nuevos campos.
shell> update-initramfs -u
Tras el reinicio, la pantalla que os saldrá de login será similar a esta (para el tema JOY).
Debian plymounth boot -JOY-
Nota: si no estáis seguros de qué tema emplear, desde una consola del sistema, no un xterminal, se puede arrancar el daemon y tras configurar plymounth ejecutarlo para una primera visualización y así ver la apariencia que tendrá.
shell> plymouthd
shell> plymouth --show-splash
Para pararlo, desde otra consola, ejecutar,
shell> plymouth --quit
Si alguien se anima a probarlo, no dude en dejar un comentario con la foto de su nuevo Debian Boot Loader ;-)

La entrada Debian Plymouth Boot Animation la puedes leer en Puppet Linux.
Leer más

IPTables, limitar número conexiones por IP

Aunque existen muchos trucos para limitar el número de conexiones por IP a un determinado servicio, cuando más a bajo nivel lo realicemos, mejor será el resultado. Si un paquete que debe ser "eliminado" sube a la capa de aplicación usará más recursos que si directamente lo eliminamos desde IPTables. Para ello, IPTables cuenta con el módulo connlimit, que limita el número máximo de conexiones que una IP puede establecer.
Se puede usar connlimit para limitar o mitigar el efecto de un ataque DDOS, y en general para limitar el número máximo de conexiones que una misma IP puede realizar a un equipo. Para hacer uso de este módulo, primeramente hay que cargarlo,
shell> modprobe xt_connlimit
Y a continuación escribir las reglas que hagan uso de dicho módulo.
shell> iptables -I INPUT -p tcp --syn --dport 80 \
       -m connlimit --connlimit-above 10 \
       -j DROP
En la regla anteriormente descrita se limita el número de conexiones de establecimiento (--syn) a 10 (--connlimit-above) por IP al servicio web (--dport). En caso de que una misma IP intente más de 10 conexiones simultáneas o en muy poco tiempo, el resto de conexiones que superen las 10 primeras será rechazadas.
Lógicamente connlimit trabaja también con IP's de entrada y de salida, así como con reglas más complejas de IPTables. La regla escrita únicamente sirve para demostrar el funcionamiento general.

La entrada IPTables, limitar número conexiones por IP la puedes leer en Puppet Linux.
Leer más

Recuperación de GRUB

El otro día me puse a cambiar la distribución de particiones de un equipo, ya que éste las tenía un tanto extrañas, y como resultado de eso, al cargarme la partición con el flag boot el sistema original no iba a arrancar. Todo se hacía desde una live, pero el que no arrancaría más iba a ser el sistema real, algo que no interesaba.
Aquí pasaron 2 cosas diferentes, por un lado cambié la partición con el flag boot, por lo que tuve que crear una nueva con dicho flag y por lo tanto ya tenía que reinstalar el GRUB. Por otro lado, a la vez que cambiaba todo, la partición raíz, anteriormente /dev/sda5 ahora pasaría a ser /dev/sda1. Esto lógicamente al GRUB no le iba a gustar, ya que su configuración le indicaba que el kernel se encontraba en la anterior partición. Así que para recuperar el sistema, por un lado había que restaurar el master boot record y por otro, actualizar la configuración de GRUB. La forma más sencilla que encontré para ello, un entorno chroot.
Para hacerlo, simplemente desde el live-cd montamos la partición del sistema original (en mi caso /dev/sda1) y luego hacemos un entorno chroot. Para hacerlo correctamente, vamos a emplear dispositivos del live-cd, ya que el sistema original, está apagado.
shell> mount /dev/sda1 /mnt
shell> mount --bind /dev /mnt/dev
shell> mount --bind /dev/pts /mnt/dev/pts
shell> mount --bind /proc /mnt/proc
shell> mount --bind /sys /mnt/sys
Ahora que ya tenemos todo lo necesario montado, ya podemos emplear chroot,
shell> chroot /mnt
Tras ejecutar este comando ya estamos 'dentro' del sistema operativo físico, por lo que todos los cambios que hagamos nos afectarán directamente, así que únicamente vamos a restaurar y actualizar GRUB.
En mi caso, voy a restaurar GRUB en /dev/sda, que es mi disco de arranque. Ojo a esto, el MBR es del disco y no de la partición.
shell> grub-install --boot-directory=/boot/ --recheck /dev/sda
Tras tener el GRUB ya instalado, si todo fue satisfactorio, simplemente ahora vamos a actualizar el listado de kerneles disponibles para el arranque, y sobre todo, la localización de los mismos, que recientemente se vio alterada.
shell> update-grub2
Tras ejecutar este comando, si vamos al fichero /boot/grub/grub.cfg podremos ver como sí actualizó la localización de los kerneles para arrancar. En mi caso pasó de sda5 a sda1. Ahora simplemente reiniciamos y todo debería de funcionar correctamente.

Nota: Si como yo, en vuestro sistema real tenéis algunas particiones separadas, lo mejor es que antes de lanzar el chroot tengáis todo montado. Si una de esas particiones es /boot, en ese caso es 100% necesario su montaje! Así que si tenéis particionado /usr, /var y /boot, antes de ejecutar la jaula chroot,
shell> mount /dev/sda2 /mnt/boot
shell> mount /dev/sda3 /mnt/usr
shell> mount /dev/sda4 /mnt/var

Si este artículo te pareció interesante, quizás te interese también ver cómo recuperar el GRUB sin emplear un Live-CD.
La entrada Recuperación de GRUB la puedes leer en Puppet Linux.
Leer más

MySQL, cambio de nombres

Hace ya tiempo que no hablaba de cosas relacionadas sobre MySQL, así que hoy voy a escribir acerca de cambios de nombres sobre tablas, columnas y bases de datos. No suele ser lo habitual, pero pueda darse el caso de que tengamos que modificar el nombre de la base de datos o de una columna por una actualización, por ejemplo, y por lo tanto sí necesitemos.

Cambio de nombre a una tabla

mysql> RENAME TABLE users TO users_tmp;

Cambio de nombre a una columna

Partimos del siguiente esquema de la base de datos,
mysql> SHOW CREATE TABLE users;
+--------+------------------------------------------+
| Table  | Create Table                             |
+--------+------------------------------------------+
| users  | CREATE TABLE `users` (
  `userid` bigint(20) unsigned NOT NULL DEFAULT '0',
  `alias` varchar(100) NOT NULL DEFAULT '',
  `name` varchar(100) NOT NULL DEFAULT '',
  `surname` varchar(100),
  `passwd` char(32) NOT NULL DEFAULT '',
  PRIMARY KEY (`userid`),
  KEY `users_1` (`alias`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1              |
+--------+------------------------------------------+
1 row in set (0.00 sec)
Y queremos cambiar el nombre de la columna surname por apellido. Aquí lo importante es la parte que viene a continuación, ya que tenemos que crear la nueva columna con el mismo tipo de datos que la vieja, para evitar pérdidas. Para ello,
mysql> ALTER TABLE users CHANGE surname apellido varchar(100);

La entrada MySQL, cambio de nombres la puedes leer en Puppet Linux.
Leer más

Protegiendo archivos PDF contra copia

Lo lógico es que cuando dejes algo a disposición de los demás, dejes que ellos puedan manejar los datos como deseen, sin embargo puede darse el caso de que te interese evitar que un archivo PDF que has enviado se pueda copiar, cuando menos de forma simple (seleccionar -> copiar-> pegar). Hoy vamos a ver un truco de 'andar por casa' que permite hacer exactamente esto, proteger un archivo PDF contra copiado, pero de forma muy sencilla. Digo que este truco de de 'andar por casa', más que nada por que no se emplea software profesional, no pagas licencias y sobre todo, el PDF resultante no lleva textos, sino imágenes. Sí, como ya os estaréis imaginando, la idea es convertir un PDF a imágenes y luego, nuevamente, volver a convertir dichas imágenes a PDF. El fichero final no permitirá la copia, puesto que ya sería necesario un OCR para hacerlo. Para trabajar únicamente necesitaremos el comando convert y, lógicamente, el fichero PDF origen.

De PDF a imagen

Para convertir el PDF original a un listado de imágenes, simplemente,
shell> convert original.pdf file-tmp.jpg
La salida que tendremos será una imagen por página, con el formato file-tmp-0.jpg, file-tmp-1.jpg, ... Tendremos tantas imágenes como páginas tenga el documentos.
convert es un comando con una infinidad de parámetros y entre otros muchos tiene uno que hace referencia a la calidad de exportación/importación con la que va a manejar las imágenes. Éste es '-quality $VALUE', así que si no hay problema de tamaño final del PDF resultante, poner una calidad óptima será lo ideal, para no perder nada de calidad, especialmente si la PDF origen tiene gráficos.

De imagen a PDF 'protegido'

Ahora ya tenemos un montón de ficheros JPG listos para ser tratadas nuevamente. Cada fichero es una página, por lo que únicamente no quedará volver a unirlos todos en el PDF resultante. Nuevamente convert,
shell> convert *.jpg final.pdf
Y tendremos el PDF, copia del original, pero protegido contra copias.

La entrada Protegiendo archivos PDF contra copia la puedes leer en Puppet Linux.
Leer más

Matar una conexión SSH remota

Fijo que a muchos de vosotros os ha pasado alguna vez. Entráis en un equipo y descubrís un usuario que está haciendo un uso del mismo que no debe, o tiene una sesión que no debiera, o cualquier otro motivo. El caso es que necesitáis terminar con dicha conexión remota. Para hacer esto existen diversas formas de lograrlo.
La primera es directamente relacionada con procesos y socket's. Cuando un usuario inicia sesión en un equipo remoto, vía SSH, se abre un socket en éste, por lo que haciendo un poco de uso de netstat y de ps, podremos saber exactamente qué proceso habrá que matar.
shell> netstat -pnat
Proto Local Address    Foreign Address     State        PID/Program name
tcp   0.0.0.0:22       0.0.0.0:*           LISTEN       2086/sshd
tcp   127.0.0.1:20001  0.0.0.0:*           LISTEN       1065/netams
tcp   127.0.0.1:3306   0.0.0.0:*           LISTEN       1697/mysqld
tcp   192.168.1.16:22  192.168.1.33:47350  ESTABLISHED  32322/sshd: javier
tcp6  :::22            :::*                LISTEN       2086/sshd
En la línea destacada en negrita se observa claramente cómo en el servidor (IP: 192.168.1.16) hay una conexión SSH establecida por el cliente 192.168.1.33 con nombre de usuario javier. También se puede observar perfectamente el PID del proceso, 32322. Por suerte, el usuario no está conectado como root, sino como usuario normal, algo lógico por seguridad. Vamos a ver por lo tanto el proceso,
shell> ps -ef | grep 32322
root     32322  2086  0 May06 ?        00:00:00 sshd: javier [priv]
javier   32325 32322  0 May06 ?        00:00:00 sshd: javier@pts/1
Todo usuario normal crea dos procesos, uno como root, que es la sesión de SSH y otro como usuario normal, que es el que realmente debemos de matar. Por lo tanto, en este caso deberíamos de matar el PID 32325. Para ello,
shell> kill -9 32325
Y al cliente le saldrá en su conexión la siguiente línea,
shell> Connection to 192.168.1.16 closed by remote host.
Connection to 192.168.1.16 closed.
Ahora ya es cuestión del administrador encargarse de que dicho usuario no vuelva a iniciar sesión en la máquina si así lo desea.
La segunda forma que vamos a ver es más simple. Es bueno siempre terminar de leerse las entradas ;-). En este caso, vamos a emplear el comando pkill, que tiene un funcionamiento muy similar a kill, sólo que no coge como parámetro el PID del proceso, sino algún otro atributo del mismo. En este caso, el número de terminal.
shell> who
javier   pts/0        2013-05-06 18:41 (:0.0)
javier   pts/1        May  6 18:56 (192.168.1.33)
Con el comando who, obtenemos el listado de los usuarios conectados al sistema. Destacamos en negrita el usuario y la sesión del mismo que queremos eliminar. Como se puede observar, está en el terminal 1 y conectado desde la IP 192.168.1.33.
Ahora hacemos uso de pkill, desde el que le mandamos una señal -9 (KILL) al proceso cuya TTY sea el terminal pts/1, tal que así,
shell> pkill -9 -t pts/1
Espero que esta entrada os pueda ser de utilidad. Siempre es bueno tener a mano los comandos necesarios para volver a tener el control del sistema y limitar los usuarios que estén dentro del equipo. Aunque, lógicamente, lo mejor es no tener que recurrir a estas técnicas.

La entrada Matar una conexión SSH remota la puedes leer en Puppet Linux.
Leer más

Actualización de pyGRUB en máquinas virtuales

pyGrub es un pequeño GRUB, escrito en Python que se instala con las xen-utils en sistemas Debian/Ubuntu y gracias al cual se manejan perfectamente las entradas de GRUB de las máquinas virtualizadas. pyGrub viene siendo la versión virtualizada de GRUB. Se instala y configura automáticamente al terminar la instalación de la máquina virtual y coge por defecto aquellos kerneles que la máquina tenga en el momento de finalizar la instalación. También modifica el fichero de configuración de la misma para indicarle que éste será su gestor de arranque.
...
bootloader = '/usr/lib/xen-default/bin/pygrub'
...
Y la apariencia que tiene es similar a la siguiente,
pyGrub Debian - Xen
Es todo prácticamente igual a lo que ya teníamos de GRUB, pero en un entorno virtual. El problema viene a la hora de actualizar el listado kerneles que tiene el sistema disponible para arrancar. Esta configuración hay que hacerla manualmente, ya que ni el comando update-grub ni update-grub2 son capaces de realizarlo.
Simplemente hay que cambiar el fichero /boot/grub/menu.lst y añadir (o sacar) las entradas que así deseemos. En mi caso, tras pasar una máquina de Ubuntu Lucid a Ubuntu Precise tuve que actualizar el fichero, pasando de ésta configuración,
default   0
timeout   2

title     Ubuntu 10.04 LTS
root      (hd0,0)
kernel    /boot/vmlinuz-2.6.32-46-generic-pae root=/dev/xvda2 ro 
initrd    /boot/initrd.img-2.6.32-46-generic-pae

title     Ubuntu 10.04 LTS (Single-User)
root      (hd0,0)
kernel    /boot/vmlinuz-2.6.32-46-generic-pae root=/dev/xvda2 ro single
initrd    /boot/initrd.img-2.6.32-46-generic-pae
A esta otra,
default   1
timeout   2

title     Ubuntu 10.04 LTS
root      (hd0,0)
kernel    /boot/vmlinuz-2.6.32-46-generic-pae root=/dev/xvda2 ro 
initrd    /boot/initrd.img-2.6.32-46-generic-pae

title     Ubuntu 12.04-3.2-virtual LTS
root      (hd0,0)
kernel    /boot/vmlinuz-3.2.0-41-virtual root=/dev/xvda2 ro
initrd    /boot/initrd.img-3.2.0-41-virtual

title     Ubuntu 12.04-3.2 LTS
root      (hd0,0)
kernel    /boot/vmlinuz-3.2.0-41-generic-pae root=/dev/xvda2 ro
initrd    /boot/initrd.img-3.2.0-41-generic-pae
Tras el cambio, desde el dom0 podemos ejecutar el siguiente comando,
shell> /usr/lib/xen-default/bin/pygrub /dev/vg0/my_domU-disk
que mostrará la apariencia que tendrá el gestor de arranque y también nos servirá para saber si está configurado como queremos.

La entrada Actualización de pyGRUB en máquinas virtuales la puedes leer en Puppet Linux.
Leer más

Linux benchmark III


Dentro de la serie de entradas que hablan sobre cómo comprobar el rendimiento de servidores GNU/Linux hoy vamos a ver cómo realizar pruebas de rendimiento sobre un servidor Apache que contenga una página web. Para ello, vamos a emplear ab (Apache Benchmark tool), que se instala automáticamente al instalara apache2-utils en nuestro sistema.
ab permite simular una solicitud de conexión a una web, pero también simular la conexión de cientos de clientes, así como la concurrencia de varios thread's simultáneamente. De esta forma podemos comprobar, más o menos, el rendimiento que tendría nuestra web con una carga de trabajo real.

Instalación

Como ya se mencionó, únicamente hay que instalar el paquete apache2-utils,
shell> apt-get install apache2-utils

Uso

ab únicamente requiere que le pasemos como argumento la URL que deseamos examinar, pero como era de esperar, también permite el paso de parámetros, lo cual facilitará enormemente el chequeo del sistema. En nuestros caso vamos a indicarle dos parámetros, el primer de ellos, opción -n, indica el número de conexiones que se van a realizar. El segundo, opción -c, indica la concurrencia de las conexiones, es decir, el número de conexiones simultáenas a la web.
shell> ab -n 1000 -c 25 http://www.your_URL.com/
Tras la ejecución del comando, nos presentará unos resultados,
Server Software:        Apache/2.2.16
Server Hostname:        www.your_URL.com
Server Port:            80

Document Path:          /
Document Length:        46701 bytes

Concurrency Level:      25
Time taken for tests:   16.897 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      47177000 bytes
HTML transferred:       46701000 bytes
Requests per second:    59.18 [#/sec] (mean)
Time per request:       422.433 [ms] (mean)
Time per request:       16.897 [ms] (mean, across all concurrent requests)
Transfer rate:          2726.54 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    3   3.1      2      24
Processing:   117  418  66.1    414     829
Waiting:       93  358  63.3    350     724
Total:        135  421  65.4    416     831

Percentage of the requests served within a certain time (ms)
  50%    416
  66%    428
  75%    436
  80%    440
  90%    459
  95%    490
  98%    664
  99%    725
 100%    831 (longest request)

Con los resultados delante, ya sólo queda interpretarlos. Lo primero de todo, dejar claro que el benchmark únicamente se ejecuta sobre la URL especificada, en mi caso sobre /indix.html y no sobre toda la web. Esto hay que tenerlo en cuenta, pues no es lo mismo un html estático que un html que lo genera un php con mucha información y acceso a base de datos. También tener en cuenta que todos los complementos adiciones que no sean html, léase javascript, css, imágenes, etc. no entran en la carga, ni por lo tanto en la comprobación de rendimiento. Aun así, Apache Benchmark es una muy buena herramienta para la realización de test a servidores web.

Interpretación

Es importante tener claro lo comentado anteriormente sobre el funcionamiento de ab. Si está claro, ya podemos interpretar los resultados. Aunque prácticamente toda la información mostrada es importante, cabe destacar por ejemplo el tiempo que tarda en ejecutarse el test, así como la cantidad de datos transmitidos. Esto nos dará una orientación sobre la cantidad de datos que descargará cada usuario que visite la URL de prueba. También es muy importante, especialmente para saber cómo afectará al posicionamiento, la relación entre el tiempo de conexión (Connection Time) y el tiempo  que tarda en generarse el documento de salida.
Es importante para tener más claro el comportamiento de nuestra web que esta prueba se ejecute varias veces con parámetros diferente, tanto en número de usuarios concurrentes, como el número de conexiones. Esto es lógico, pues no es lo mismo tener un único usuario navegando que tener 200 simultáneos.

Espero que esta aproximación a ab os deje con ganas de más información. Si la queréis no dudéis de dejar un comentario ni tampoco de leer el manual de la aplicación, que sin duda ayudará mucho.

La entrada Linux benchmark III la puedes leer en Puppet Linux.
Leer más

Debian Wheezy is out!

Éste fue un fin de semana intento. La nueva versión de Debian salió oficialmente a la luz. Después de 27 meses de continuo esfuerzo Debian Wheezy salió finalmente a la luz con novedades importantes, tanto para escritorio como para equipos Desktop. Un avance en versiones de software realmente importante.
Como era lógico, antes de escribir algo acerca de la nueva versión había que probarla, así que tocó ponerse a trabajar y la nueva release ya está instalada en mi desktop.


shell> cat /etc/debian_version
7.0
Lo más destacada en cuanto a software se refiere son las nuevas versiones de paquetes que ya tenía. Una actualización a versiones más recientes completamente necesaria. Por destacar,
  • GNOME 3.4
  • KDE 4.8.4
  • GIMP 2.8.2
  • Linux Kernel 3.2
  • MySQL 5.5.30
  • Samba 3.6.6
  • Hipervisor Xen 4.1.4
  • Y como no, Xfce 4.8
Sin embargo, lo más destacado de la nueva versión de Debian es el soporte multiarquitectura. Algo que sin duda se estaba pidiendo desde hace ya tiempo y que otras distribuciones ya tenían. Ahora podremos instalar paquetes de 32 y de 64 bits sobre la misma máquina con todas las dependencias perfectamente resueltas.
También se destaca el nuevo instalador, mucho más simple y rápido, que ahora tiene soporte para instalación con voz. Además también se han re-escrito los manuales de instalación, que los puedes consultar aquí (en español).
Pero sin duda, lo que más destaca de la nueva versión es todo lo relacionado con el sistema operativo en sí, y que afecta directamente a los servidores más que a los desktop's. Una nueva versión de MySQL, por fin la versión 5.5! Nueva versión de Apache, Samba y mucho más software actualizado. Sin embargo, algo que salta a primera vista tras la instalación es la nueva localización de los puntos de montaje de los sistemas de ficheros temporales.
shell> mount
...
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=206420k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,relatime,size=803200k)
...
En versiones anteriores los puntos de montaje de los sistemas de ficheros tmpfs estaban bajo /lib/init/rw, /dev/shm/ y en ocasiones /var/lock. En la nueva versión estos puntos de montaje se pasan a /run, excepto /lib/init/rw, que se ha eliminado directamente. Estos nuevos puntos de montaje de /run son ahora configurados desde /etc/default/tmpfs, pero la configuración no es automáticamente migrada. Así que ojo si tenéis algún sistema funcionando sobre /dev/shm/, que tras la actualización podrá tener fallos.
En cuanto tenga alguna experiencia más sobre el uso de Wheezy os la iré comentando, así que todos los posibles "fallos" que aparezcan a la hora de actualizar servidores en producción.
Por cierto, para aquellos curiosos que se lo estén preguntando. La nueva versión testing de Debian se llama Jessie. Si es que Debian, no deja de trabajar!
Más información:
La entrada Debian Wheezy is out! la puedes leer en Puppet Linux.
Leer más

Simplificando ssh, ~/.ssh/config

Si sois de los que empleáis SSH para acceder a vuestros equipos, bien hecho!, pero estaréis de acuerdo conmigo cuando os diga que en muchas ocasiones el acceso SSH depende de parámetros y si manejáis una gran cantidad de equipos, recordarlos todos puede llegar a ser una tarea hercúlea.
Pues bien, para simplificar esta tarea, SSH incluye un pequeño fichero de configuración, local a cada usuario, que permite recordar y automatizar esos pequeños parámetros de forma sencilla. El fichero en cuestión es ~/.ssh/config y sobre él podemos definir los equipos a los que queremos acceder, el puerto sobre el que hacer login, usuario, la clave rsa/dsa que se emplear, etc. Algo que resultará práctico.
A continuación os dejo un ejemplo sencillo de cómo emplearlo para que veáis el valor que tiene.
Host github.com
   User git
   Hostname github.com
   PreferredAuthentications publickey
   IdentityFile ~/.ssh/clave_rsa_github

Host web
   User apache
   Port 2222
   Hostname 192.168.1.100
Ahora únicamente bastaría con que nuestro usuario intentase acceder a los equipos por SSH y una simple llamada,
shell> ssh web
Se convertiría automáticamente a,
shell> ssh -p 2222 apache@192.168.1.100

La entrada Simplificando ssh, ~/.ssh/config la puede leer en Puppet Linux.
Leer más

Nmap idle-scan

Hoy os voy a hablar sobre una técnica de escaneo de puertos con nmap que intenta evitar el filtrado de firewall's. Es lo que se conoce como nmap idle-scan. idle-scan es el nombre con el que se conoce a la técnica de escaneo que haciendo uso de hosts zombies oculta completamente la IP origen del escaneo. No ofusca la IP origen de la conexión, sino que ni siquiera envía un sólo paquete al destino. Esta técnica es una de las mejores para saltarnos firewall's e IDS.
El funcionamiento de idle-scan es realmente una técnica compleja en cuanto a escaneos de puertos se refiere, pero se basa en las siguientes premisas (a groso modo):
  • Un sistema operativo escucha en determinados puertos TCP al igual que un servidor web escucha en el 80 o uno de correo en el 25.
  • Un puerto se considera abierto si un servicio está escuchando en dicho puerto, cerrado sino.
  • Para establecer una conexión a un puerto, se envía un paquete "SYN" al puerto. Si el puerto está abierto y a la escucha, enviará un "SYN/ACK", en caso contrario un "RST".
  • Una máquina que reciba un paquete "SYN/ACK" no solicitado responderá con un "RST". Un "RST" no solicitado será automáticamente ignorado.
  • Cada paquete IP tiene un número de identificación (identificación de fragmento). Muchos de los SO actuales incrementan este número por cada paquete que envían, por lo que la observación es este número puede indicar cuántos paquetes se enviaron desde la última conexión.
Realizando una combinación de todos las características anteriormente descritas es a nivel general en lo que se basa la técnica idle-scan, representada gráficamente a continuación.
nmap - idle-scan
Para poder usarlo tal como se muestra en la figura, debemos de seguir un par de sencillos pasos.
  1. Seleccionar un host 'zombie'
    Este host que debemos de seleccionar, para que la técnica funcione, debe tener el IPID incremental. Existen numerosas formas de averiguar si un equipo tiene o no el IPID incremental, una de ellas es directamente con el propio nmap (plugin ipidseq.nse). Otra es empleando metasploit. Para completar el ejemplo, vamos a emplear metasploit.
    shell> msfcli scanner/ip/ipidseq RHOSTS=192.168.0.0/24 E
    
    En ejecutar el comando anterior tardará un tiempo, así que sed pacientes. Cuando termine nos dará un listado de aquellos host's con el IPID incremental que haya en la red.
  2. Lanzar nmap
    Ahora que ya tenemos la víctima puente para poder lanzar el ataque y estar perfectamente camuflados, únicamente hay que lanzarlo.
    Vamos a suponer que el host zombie empleado sea el 192.168.0.201 y el equipo a escanear el 192.168.0.15. Si lanzamos un nmap directamente contra ese equipo, aparte de dejar rastros de la IP que hace el escaneo, puede que un posible firewall nos detecte e impida la conexión.
    shell> nmap -PN -P0 -p445 192.168.0.15
    PORT     STATE     SERVICE
    445/tcp  filtered  microsoft-ds
    
    Sin embargo, si empleamos el zombie, veremos los sigueinte,
    shell> nmap -PN -P0 -p445 -sI 192.168.0.201 192.168.0.15
    PORT     STATE     SERVICE
    445/tcp  open      microsoft-ds
    

¿Qué ventajas ofrece idle-scan?

  • Sigilo
    No se envía ningún paquete con la IP del atacante, por lo que su identidad está completamente a salvo.
  • Evasión
    Al no realizar ninguna conexión directa, tanto firewall como IDS tienen más difícil detectar como filtrar el escaneo. No existe una IP origen que bloquear, ya que puede que la IP "origen" sea un equipo de la propia red, el cual sí está permitido.
Más información sobre idle-scan en nmap.org

La entrada Nmap idle-scan la puede leer en Puppet Linux.
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios