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.

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.

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.

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.

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.

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.