El error del título podemos verlo tanto en la salida del comando dmesg como en el log messages. Básicamente nos está indicando que se están denegando paquetes debido a que la tabla/buffer de netfilter nf_conntrack/ip_conntrack, donde se almacena un registro de las conexiones activas en la máquina está llena:

# dmesg
...
...
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
...
...

El problema puede residir tanto en un ataque puntual o que realmente el tráfico legítimo que recibe la máquina es muy grande. Tanto en un caso como en otro la solución rápida es modificar este parámetro del kernel y aumentar su valor. Os recomiendo revisar este otro artículo sysctl y /proc/sys – modificar parámetros de kernel para ampliar la información.

Lo primero que debemos ver es, por un lado el valor máximo actual y el valor en uso:

$ cat /proc/sys/net/netfilter/nf_conntrack_count
62686
$ cat /proc/sys/net/netfilter/nf_conntrack_max
65536

La primera orden nos dice el número de entradas en la tabla y el segundo el máximo. Como vemos estamos a punto de llegar al límite. Cuando esto suceda se comenzarán a descartar paquetes. Podemos entonces ampliar temporalmente (no sobrevive a renicios) el nº de entradas máximas en la tabla (ponemos el doble):

# sysctl -w net.netfilter.nf_conntrack_max=131072
net.netfilter.nf_conntrack_max = 131072

Si quisieramos hacerlo persistente a reinicios, lo modificaríamos en el fichero /etc/sysctl.conf añadiendo:

net.netfilter.nf_conntrack_max=131072

Hoy vamos con una entrada de las tontas, de esas que por no mirar un log tardamos más de lo debido en resolver el problema. En este caso algo tan simple como configurar el acceso sin password y con llaves públicas de ssh me ha tenido unos minutos intrigado.

Básicamente, el problema ha sido por una configuración de umask un poco puñetera para el usuario:

$ umask
0002

Para los que no tengáis claro como funciona umask, revisad este artículo: El comando umask. En este caso al crear el fichero authorized_keys para almacenar las llaves públicas, este umask ha provocado que se creara con permisos muy poco seguros…

-rw-rw-r--. 1 foo foo    0 ene 27 22:12 authorized_keys

Y claro, ssh decía que de esta no era la forma correcta en el /var/log/secure:

Jan 27 21:55:52 nodo2 sshd[3282]: Authentication refused: bad ownership or modes
for file /home/foo/.ssh/authorized_keys
Jan 27 21:55:53 nodo2 sshd[3284]: Connection closed by 192.168.1.128

Securizamos con un 400 o 600 y solucionado:

$ chmod 600 /home/foo/.ssh/authorized_keys

Yo estaba empeñado en que era problema de SElinux, pero al ver que el modo permisivo no hacía que se solucionara el próximo paso tenía que ser mirar messages o secure.

Instalar y configurar el servidor VNC TigerVNC es realmente sencillo. Lo que muchas veces no nos paramos a pensar es que el protocolo en sí no es seguro por lo que el tráfico no está cifrado al conectar al escritorio remoto. Vamos a ver como solucionarlo.

Lo primero es instalar TigerVNC con yum (RHEL, CentOS, Scifi linux, etc). En este caso instalo también el cliente para hacer las pruebas en local:

# yum install tigervnc-server tigervnc

Una vez instalado debemos saber que la configuración se realiza en el fichero /etc/sysconfig/vncservers. Los comentarios del fichero nos indican claramente como configurarlo, también hice un artículo hace un tiempo, echadle un vistazo: Instalar y configurar vnc-server en CentOS/RHEL/Fedora

He creado un usuario “alex” al que únicamente se le permite el acceso local por seguridad:

# The VNCSERVERS variable is a list of display:user pairs.
#
# Uncomment the lines below to start a VNC server on display :2
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see this URL:
# http://kbase.redhat.com/faq/docs/DOC-7028

# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.

# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.

# VNCSERVERS="2:myusername"
# VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"
VNCSERVERS="2:ale
VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"

Creamos el password VNC para el usuario del siguiente modo:

# su alex -c "vncpasswd"
Password: XXXX
Verify: XXXX

Arrancamos el servidor VNC para el usuario alex:

[alex@localhost /]$ vncserver
xauth:  creating new authority file /home/alex/.Xauthority

New 'rhcsa:1 (alex)' desktop is rhcsa:1

Starting applications specified in /home/alex/.vnc/xstartup
Log file is /home/alex/.vnc/rhcsa:1.log

Llegados a este punto podemos acceder sin problemas en local al escritorio remoto con el comando vncviewer:

$ vncviewer localhost:1

Desde fuera no, por motivos de seguridad. Para ello vamos a crear un tunel SSH de modo que las conexiones VNC con el exterior sí que estén cifradas. Vamos a usar por ejemplo el puerto 6922 para el tunel. El servidor VNC se encuentra en la IP 10.0.0.100, desde el equipo remoto con el que queremos conectar al servidor creamos el tunel:

$ ssh alex@10.0.0.100 -L 6922:10.0.0.100:5901 -N

Y ya está, podemos acceder remotamente al servidor VNC de forma segura con el nuevo puerto:

$ vncviewer localhost:6922

Si queréis usar el estandar podéis mantener los puertos de VNC:

$ ssh alex@10.0.0.100 -L 5901:10.0.0.100:5901 -N

$ vncviewer localhost:1

En el caso de necesitar registrar un sistema RHEL en la Red Hat Network y el equipo no tenga salida a Internet porque se encuentra en una red privada, existe la posibilidad de habilitar el acceso vía proxy. Para ello usamos el comando rhn_register como siempre, pero añadiendo el proxy como parámetro:

# rhn_register --nox --proxy=proxy:puerto

# rhn_register --nox --proxy=10.0.0.100:8080

Si el proxy requiere autenticación usamos los parámetros –proxyUser=PROXYUSER y –proxyPassword=PROXYPASSWORD.

Por otra parte, también necesitaremos utilizar yum para instalar aplicaciones o parchear el sistema una vez registrado. Para ello únicamente tenemos que especificar el proxy en el fichero de configuración de yum /etc/yum.conf:

proxy=http://10.0.0.100:8080/
proxy_username=usuario
proxy_password=password

La barra final parece ser necesaria, a mí no me funcionaba sin ella.

Tanto para cambiar el directorio por defecto al que acceden usuarios anónimos en un servidor FTP como usuarios autenticados, en el caso de que el sistema esté configurado con SELinux en modo Enforcing hay que tener en cuenta la necesidad de reconfigurar los permisos de forma correcta y que el servicio funcione.

# getenforce
Enforcing

En el servidor vsftpd para modificar el directorio por defecto al que acceden los usuarios anónimos (/var/ftp) es necesario añadir la siguiente directiva en el fichero /etc/vsftpd/vsftpd.conf:

anon_root=/publico

Esto sería suficiente en un servidor normal, bueno, podría ser necesario cambio de propietario/grupo del directorio o de los permisos pero no siempre. En cambio, si tenemos SELinux activado hay que configurar los permisos SELinux igual que los tiene la carpeta original /var/ftp. Si no lo hacemos, veremos bloqueos en el log /var/log/audit/audit.log:

"/usr/sbin/vsftpd" subj=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1325536433.909:63): avc: denied { read } for  pid=3159 comm="vsftpd" name="testt" dev=dm-0 ino=22445 scontext=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
type=SYSCALL msg=audit(1325536433.909:63): arch=40000003 syscall=5 success=no exit=-13 a0=2523228 a1=98800 a2=adc33c a3=bfd18cb4 items=0 ppid=3157 pid=3159 auid=0 uid=14 gid=50 euid=14 suid=14 fsuid=14 egid=50 sgid=50 fsgid=50 tty=(none) ses=1 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)

Lo más sencillo es usar el comando chcon con el parámetro –reference, de modo que le especificamos el origen del cual copia los permisos contra la nueva ubicación:

# ls -Z /var/ | grep ftp
drwxr-xr-x. root root system_u:object_r:public_content_t:s0 ftp

# ls -Z | grep publico
drwxr-xr-x. root root system_u:object_r:root_t:s0      ftp

# chcon --reference=/var/ftp /publico -R

# ls -Z | grep publico
drwxr-xr-x. root root system_u:object_r:public_content_t:s0 ftp

Reiniciamos el servicio y el acceso a toda la información del nuevo directorio ya debería ser correcta:

# /etc/init.d/vsftpd start

Hemos puesto el caso de un servidor FTP, pero esto es válido para cualquier servicio (Apache, MySQL, Exim, Postfix…)

Llevo unos días haciendo pruebas con una maqueta de Red Hat Cluster Suite en CentOS. De momento, voy estudiando los distintos comandos y ficheros de configuración, aunque utilizo luci/ricci para la gestión del cluster vía web.

Uno de los primeros problemas que me encontré es de lo más simple. La idea es crear un recurso IP, que levanta una IP virtual en uno de los nodos del cluster. Esa IP la podemos utilizar posteriormente como recurso para un servicio HTTP ó MySQL por ejemplo, IP que en caso de fallo del nodo activo se traspasará junto con el resto de servicio a otro nodo del cluster.

Lo único que hay que tener claro es que la subred de esa IP debe estar configurada en alguna de las interfaces de red de los nodos, sino el rgmanager no sabrá donde levantarla. La máscara es opcional, pero por ahí venían todos mis problemas. Recibía el siguiente error al levantar el servicio:

Dec 28 21:41:53 nodo1 rgmanager[3563]: Initializing service:IP
Dec 28 21:42:32 nodo1 rgmanager[3563]: Recovering failed service service:IP
Dec 28 21:42:32 nodo1 rgmanager[3563]: start on ip "192.168.1.200/255.255.255.0" returned 1 (generic error)
Dec 28 21:42:33 nodo1 rgmanager[3563]: #68: Failed to start service:IP; return value: 1
Dec 28 21:42:33 nodo1 rgmanager[3563]: Stopping service service:IP
Dec 28 21:42:35 nodo1 rgmanager[3563]: Service service:IP is recovering

Y la configuración del recurso/servicio:

<service autostart="0" domain="IP_FAILOVER" name="IP" recovery="relocate">
<ip address="192.168.1.200/255.255.255.0" monitor_link="1" sleeptime="10"/>
</service>

El problema, tras darle unas cuantas vueltas era tan simple como que la máscara se especifica como bits de máscara de red, es decir, en lugar de 255.255.255.0, 24:

<service autostart="0" domain="IP_FAILOVER" name="IP" recovery="relocate">
<ip address="192.168.1.200/24" monitor_link="1" sleeptime="10"/>
</service>

Tratamos de arrancar el servicio y ya levanta la IP virtual correctamente. Puede parecer una tontería pero es útil tenerlo en cuenta por si os pasa.

Dec 28 21:47:31 nodo1 rgmanager[3331]: Starting stopped service service:IP
Dec 28 21:47:37 nodo1 rgmanager[8561]: [ip] Adding IPv4 address 192.168.1.200/24 to eth0
Dec 28 21:47:44 nodo1 rgmanager[3331]: Service service:IP started

Ya he hablado en otras ocasiones de Kickstart, explicando el modo de automatizar instalaciones de CentOS con Kickstart. En este caso el proceso es igual, pero aplicándolo a la automatización en virtualización. Si desconocéis como funciona Kickstart/Anaconda os recomiendo revisar antes ese post.

Vamos a ver como automatizar la instalación de máquina virtuales, en este caso KVM, pero es aplicable a Xen y otros sistemas de virtualización.

Vamos a hacer uso de la herramienta virt-install para las instalaciones. Esta es la línea de comandos que podemos usar para instalar una máquina virtual Scientific Linux (sería igual para RHEL, CentOS, Fedora…) sin intervención manual:

# virt-install  --name testKS \
                --ram 512 \
                --disk /var/lib/libvirt/images/testks.img,size=5 \
                 -l "ftp://ftp.scientificlinux.org/linux/scientific/6.1/x86_64/os/" \
                 -x "ks=ftp://192.168.1.130/pub/ks.cfg"

Starting install...
Retrieving file .treeinfo...                           |  768 B     00:00 ...
Retrieving file vmlinuz...                             | 7.4 MB     00:05 ...
Retrieving file initrd.img...                          |  68 MB     00:53 ...
Creating domain...                                     |    0 B     00:00

Los parámetros utilizados son los siguientes:

• –name: nombre de la máquina virtual.
• –ram: tamaño de memoria RAM en MB.
• –disk: ruta y nombre del fichero .img que será utilizado como disco duro virtual. Tras la ruta a la imagen se especifica el tamaño en GB de la imágen (5).
• -l (–location): especifica el lugar donde se encuentra el instalador del sistema (vmlinuz e initrd.img), en este caso especificamos el respositorio oficial de Scifi Linux y la ruta exacta para 64bits.
• -x (–extra-args): especificamos argumentos extra para la instalación, en este caso tiene que ser la ruta al fichero Kickstart que tiene toda la configuración del proceso de instalación.

Y esto es todo. Si el fichero Kickstart está bien, se realizará una instalación totalmente desatendida del sistema operativo.

Esta mañana nos encontrábamos instalando una máquina virtual Debian Squeeze a través de netinstall y por restricciones de seguridad hemos tenido que configurar vía proxy la descarga de paquetes para la instalación.

Una vez instalado e intentar actualizar el sistema nos hemos dado cuenta que seguíamos usando el proxy al usar apt/aptitude. Cuando instalamos Debian a través de un proxy, luego hay que desactivarlo en apt si no queremos seguir usándolo.

Para ello, debemos eliminar las líneas en /etc/apt/apt.conf que contienen la configuración del proxy: Acquire::http::Proxy ó Acquire::ftp::Proxy seguido de la URL del proxy:

Acquire::http::Proxy "http://miproxy.com:8213";
Acquire::ftp::Proxy "http://miproxy.com:8213";