Categoría: Linux

Pasando de sysvinit a systemd en Fedora

En las Notas de lanzamiento de la documentación de Fedora 16 nos encontramos con lo siguiente:

3.2.4. Scripts de SysVinit portados a systemd

Fedora 15 vió la introducción de systemd, un administrador de sistema y de servicios nuevo para Linux. La integración de systemd continúa en Verne, con muchos más scripts de inicio de SysV convertidos a archivos de servicios nativo de systemd. El resultado es un proceso de arranque más rápido, eficiente y una administración de servicios más simple.

Ahora bien, si entrar a valorar si el cambio ofrece mejoras, que seguro que si y pronto lo veremos también en Red Hat Enterprise, CentOS y el resto de la familia, pero el abandono de sysvinit trae consigo la necesidad de adaptarse al nuevo sistema.

Por el momento se puede hacer uso de service y chkconfig, aunque creo que poco durarán en futuras versiones, así que toca ponerse al día para poder administrar los servicios con systemd, ahí van algunos comandos y sus correspondencias con sysvinit:

SYSVINIT SYSTEMD Función
service httpd start systemctl start httpd.service Utilizado para arrancar el servicio (no resiste reinicio)
service httpd stop systemctl stop httpd.service Utilizado para detener el servicio (no resiste a reinicio)
service httpd restart systemctl restart httpd.service Utilizado para detener y arrancar el servicio.
service httpd reload systemctl reload httpd.service Cuando se soporta, recarga el archivo de configuración sin interrumpir las operaciones pendientes.
service httpd condrestart systemctl condrestart httpd.service Rearranca el servicio sólo si ya está ejecutándose.
service httpd status systemctl status httpd.service Indica si el servicio está en ejecución o no.
ls /etc/rc.d/init.d/ ls /lib/systemd/system/*.service /etc/systemd/system/*.service Utilizado para listar los servicios que pueden ser iniciados o detenidos
ls /etc/rc.d/init.d/ systemctl list-units –all Utilizado para listar todos los servicios y otros units
chkconfig httpd on systemctl enable httpd.service Pone el servicio en «on», para que se inicie cuando se inicie la máquina u otro disparador como cambio de nivel de ejecución.
chkconfig httpd off systemctl disable httpd.service Pone el servicio en «off» para que al iniciar el sistema, no se inicie el servicio o se detenga por ejemplo al momento de cambio de nivel de ejecución.
chkconfig httpd systemctl is-enabled httpd.service Utilizado para verificar si un servicio está configurado para ser iniciado en el entorno actual.
chkconfig httpd –list ls /etc/systemd/system/*.wants/httpd.service Utilizado para listar qué niveles de ejecución el servicio está en «on» o «off».
chkconfig httpd –add systemctl daemon-reload Utilizado para cuando se desea crear un nuevo archivo de servicio o modificar su configuración.

Más info en: https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet/es

Reconocer dispositivos en un sistema Linux

En un sistema Linux es importante tener claro como se nombran los diferentes dispositivos, para ello los nombres se inician por un prefijo que indica el tipo de dispositivo del que se trata. Estos son algunos de ellos:

Prefijo Tipo
hd Particiones de discos duros IDE
sd Particiones de discos duros SCSI
sr Discos CD-ROM SCSI
fd Disquetes
st Dispositivos de cinta SCSI
ht Dispositivos de cinta IDE
tty Terminales
lp Impresoras
pty Terminales remotos
js Puertos joystick
midi Puertos MIDI
ttyS Puertos serie
cua Puertos COM
cdrom Discos CD-ROM
modem Modems
vd Discos duros virtuales en sistemas virtualizados

Estos prefijos se combinan con el identificador del dispositivo. Así en los discos duros IDE tendríamos para el primer disco la letra «a» seguida de un número para identificar la partición. Con hda1 se identificaría la primera partición del primer disco duro IDE. Con hdb2 tendríamos la segunda partición del segundo disco IDE.

Todos los dispositivos se almacenan en el directorio /dev, listado este directorio se mostrarán todos los dispositivos conectados.

Usando repositorios de YUM

En sistemas Red Hat y derivados (Fedora, Oracle Linux, CentOS, etc) podemos usar YUM para gestionar la instalación de paquetes, una herramienta que facilita mucho la vida a cualquier administrador de sistemas.

Los repositorios se configuran bajo el directorio /etc/yum.repos.d/ y deben tener la terminación .repo. En cada uno de los ficheros pueden estar configurado más de 1 repositorio, para agregar un repositorio debemos poner los siguientes campos:

[nombre_repositorio]
name=Nombre del repositorio
baseurl=http://servidor/repositorio
enabled=1
gpgkey=http://servidor/repositorio/gpgkey
pgpcheck=1

En name indicamos el nombre, con baseurl la ruta hasta el repositorio, con enabled si se habilita (1) o no (0), con gpgkey la ruta de la llave de seguridad y con pgpcheck si se comprueba la integridad con la llave.

Una vez completado guardamos el fichero repositorio.repo por ejemplo y lanzamos el listado de repositorios que debería mostrarnos algo como lo siguiente:

# yum repolist

repo id repo name status
base CentOS-5 – Base 3558+8
extras CentOS-5 – Extras 290
updates CentOS-5 – Updates 676+40
repolist: 4524

Y ya tenemos configurado nuestro repositorio. Si estáis buscando información para configurar repositorios en este enlace tenéis EPEL (Paquetes adicionales para Linux Empresarial, incluyendo CentOS, Oracle Linux, etc).

Proteger el acceso por SSH (II)

Después de haber configurado el servicio SSH para hacerlo un poco más seguro, hoy vamos con la segunda entrega. En este caso vamos a ver como asegurar nuestro servidor SSH mediante el uso de certificados, un paso más allá que evitará que el servidor solicite autenticación si previamente no se ha enviado un certificado.

El primer paso será generar un certificado en el equipo cliente, para ello podemos optar por dos alternativas, la primera usar la ssh-keygen y la segunda utilizar la PuTTYgen. Si utilizáis indistintamente la shell y el PuTTY para acceder a servidores remotos entonces deberíais usar los dos formatos. Accedemos al equipo cliente y lanzamos el comando:

# ssh-keygen

Nos pedirá la ruta donde queremos guardar el fichero (pulsando enter se guardará en la ruta por defecto), y luego nos pedirá el passphrase. Se podría dejar en blanco y que simplemente se accediese al servidor sin ninguna contraseña, pero como hablamos de la seguridad lo primero usaremos un passphrase. También podemos omitir estos pasos indicandolos como parametros:

# ssh-keygen [-b bits] -t type [-N passphrase] [-f fichero]

Con la opción -b indicamos el número de bits, por defecto son 2048 y el valor mínimo es 768. Con -t indicamos el tipo (rsa o dsa, por defecto rsa que es el que usaremos). Con -N indicamos el passphrase y con -f el fichero de salida del certificado.

Una vez completado tendremos dos ficheros en la ruta especificada id_rsa e id_rsa.pub, que como parece obvio es el que contiene la clave pública, mientras que id_rsa contiene la clave privada.

Ahora toca trasladar al servidor la clave pública, para ello podemos echar mano del comando ssh-copy-id del siguiente modo:

# ssh-copy-id [-i fichero_clave] usuario@servidor

Con la opción -i indicaremos el fichero que contiene la clave pública generada en el paso anterior. Solicitará el passphrase y se instalará en .ssh/autorized_keys

Una vez completado este paso ya podemos acceder al servidor mediante el uso de los certificados y en lugar de pedir el password nos pedirá el passphrase. Ahora nos queda hacer que el servidor no responda ninguna petición si no viene acompañada de certificado, para ello editamos el fichero /etc/ssh/sshd_config, cambiamos la directiva PasswordAuthentication a no y reiniciamos el servicio sshd.

Ya sólo nos queda una cosa más. Si accedéis por SSH usando PuTTY entonces necesitareis convertir vuestro certificado. Para ello echaremos mano de PuTTYgen, en el menú Conversiones >> Importar clave y buscaremos el fichero de clave privada (id_rsa). Pulsamos en Generar y luego en Guardar clave privada.

Ahora ya tenemos nuestra clave privada en formato ppk. Para usarla con PuTTY tendremos que acceder a Connection >> SSH >> Auth e insertar ahí la clave, luego loguearnos como de costumbre.

Proteger el acceso por SSH

SSH (Secure SHell) es a un tiempo el nombre del protocolo y el programa que nos permite acceder a maquinas remotas de forma segura y gestionarlas por completo mediante un intérprete de comandos.

Hechas las presentaciones, vaya por delante lo de siempre: un servidor completamente seguro es el que está encerrado entre muros de hormigón sin ningún tipo de conexión. Obviamente, así no sirve para nada, entonces tendremos que buscar el correcto equilibrio entre conectividad y seguridad. Como me toca acabar el año configurando nuevos servidores, os dejo una pequeña guía para asegurar el acceso por SSH.

Lo primero, modificar el fichero de configuración de SSH que encontrareis en /etc/ssh/sshd_config y agregamos las siguientes líneas (en muchos casos las encontrareis comentadas).

Protocol 2
LoginGraceTime 20
PermitRootLogin no
MaxAuthTries 2
MaxStartups 3
AllowUsers pepito

La primera línea le indica que unicamente se puede hacer uso de la versión 2 del protocolo de comunicación. La primera versión tiene algunas vulnerabilidades conocidas y está obsoleta por lo que lo recomendable es no usarla si no se necesita.

El LoginGraceTime hace referencia al tiempo en segundos que la pantalla de login permanecerá abierta, en el ejemplo hemos dejado 20 segundos, un tiempo más que suficiente para indicar usuario y contraseña.

Con PermitRootLogin establecido a no evitaremos que el usuario root pueda autenticarse a través de SSH para acceder al servidor. El problema es que los sistemas Linux y Unix crean al usuario root, lo que garantiza a un atacante que ya conoce el usuario, sólo queda la contraseña. De esta forma será mucho más complicado, obviamente no uses nombres conocidos o estarás en el mismo caso.

Otro de los límites que podemos imponer es definir la cantidad de veces que podemos fallar al autenticarnos. Con MaxAuthTries definimos el número de intentos, con 1 sería más que suficiente, pero a los que nos toca andar con varios servidores a la larga terminas equivocándote la primera vez de ahí que lo defina con 2 intentos. Lo que ocurrirá después del segundo fallo es que se cerrará la conexión.

Con MaxStartups se indican la cantidad de conexiones simultaneas que se permiten, en este caso hemos optado por 3, un número razonable para aquellos servidores a los que se accede por SSH únicamente para su administración. Con esto evitaremos que un ataque por fuerza bruta pueda realizar miles de conexiones simultaneas para atacar.

Y por último, pero no menos importante, AllowUsers. Con esta directiva le indicamos al SSH que usuarios exclusivamente se pueden identificar en el sistema. También podemos aumentar la seguridad definiendo desde que redes puede acceder un determinado usuario. Basta con poner los nombres de los usuarios separados por espacios, si se quiere indicar un host podemos hacerlo poniendo el usuario seguido del símbolo @ y el host (Ej: pepito@127.0.0.1).

Con esto ya tenemos nuestro SSH un poco más seguro. Guardamos el fichero y reiniciamos el servicio.

Lo segundo que haremos para evitar que nos ataquen será instalar Fail2ban, un programa controla los logs y que nos permite vetar todas aquellas IP’s que fallan un determinado número de veces. El baneo se realizará usando el firewall, así que lo que hace realmente Fail2ban es crear y borrar reglas en función de la información que se registra en los logs.

El requisito para instalar Fail2ban es tener Python, tenéis disponibles paquetes compilados para instalar o podeis tirar de repositorios. Una vez instalado tan solo es necesario configurar las reglas que queremos tener activas, tenéis bastante información en su web y un archivo de configuración de prueba en /etc/fail2ban/jail.conf

Proteger acceso por SSH con certificados

Limitar el tamaño máximo del correo con Qmail

Algo muy frecuente, más de lo que parece a pesar de que el sentido común indique lo contrario, es que los usuarios de un servidor de correo intenten enviar auténticos «ladrillos» a través del correo electrónico. Para la mayor parte de los usuarios 100 KB o 100 MB les suena más o menos a lo mismo e intentarán enviarlo a través del correo sin siquiera pararse a pensar si es o no razonable.

Un amigo hizo una buena comparación para que se vea la diferencia, en el caso de los 100 MB es como si se intentase enviar por correo postal una lavadora, a todo el mundo le parecería una autentica barbaridad.

Para evitarlo, podemos limitar el tamaño máximo de los correos que son enviados con Qmail. Para ello nada más sencillo que indicar el tamaño máximo en el fichero /var/qmail/control/databytes que se quiere establecer expresado en bytes. Por ejemplo para limitar el tamaño de los correos a 10 MB escribimos en el fichero 10485760 .

Guardamos el fichero y reiniciamos el servicio, con esto ya estará establecido el límite máximo del tamaño del correo. El usuario recibirá un mensaje o un correo de aviso de que no puede enviar más «ladrillos» por email.

Límite de conexiones IMAP con Qmail en Plesk

Por defecto el límite de las conexiones máximas de imapd que se configura con Qmail en Plesk es bastante bajo, y probablemente te encontrarás con problemas a la hora de tener varias cuentas sincronizadas con el servidor de correo.

En Qmail se establecen los valores MAXPERIP y MAXDAEMONS con un límite realmente bajo, aunque esa limitación a la baja venga motivada por no sobrecargar el servidor, evitando abusos de uso de memoria y CPU. Para modificar estos parámetros debes editar el archivo /etc/courier-imap/imapd y aumentar esos valores. Una vez editado el archivo no olvidar reiniciar el servicio para aplicar los cambios.

No eleves demasiado el límite, pues podrías sobrecargar el servidor, es mucho mejor aumentar poco a poco esos valores hasta conseguir establecer el límite justo un poco por encima de lo que se necesita.