Tras mi experiencia de 5 años como sysadmin Linux, he aprendido qué cosas evitar a la hora de tener un servidor Debian relativamente seguro.
Casi todas estos consejos parten de la paranoia y algunos simplemente se rigen por el sentido común, pero merece la pena listarlos y revisarlos de vez en cuando.
Allá vamos:
- Utilizar siempre que sea posible conexiones cifradas cuando vamos a trabajar con datos sensibles:
Protocolos como SSH, SCP y https fijan transmisiones de datos cifradas.
Con ello evitamos ademas de que nos snifen el tráfico, pudiendo acceder a datos sensibles y contraseñas, ataques tipo man in the middle.
- Password robustos y encriptados:
Utilizar siempre password robustos. “Churros” de mínimo ocho caracteres, con al menos un caracter en mayúsculas, uno en minúsculas y uno numérico.
Ejemplo: Ax84jMn4
Es de sentido común que el password de root de nuestro sistema no sea ’12345′.
- Mantener el servidor actualizado.
Debian especialmente y en general las distribuciones derivadas suelen tener un exhaustivo control de actualizaciones y reparaciones de bugs. Para ello, tenemos que tener entre nuestros repositorios, los repositorios oficiales de seguridad
Actualizar un sistema debian es tan facil como teclear:
apt-get update
apt-get upgrade
- Cuidado con el software de origen dudoso .
Vigilar qué tenemos en nuestro fichero sources.list. Intentar utilizar solo repositorios oficiales.
- Desinstalar o deshabilitar servicios innecesarios
Para ello podemos hacer uso del comando chkconfig (originario de distribuciones basadas en rpm, existe también para debian)
La idea es parar y deshabilitar el arranque de servicios que no vamos a necesitar.
- FIREWALL
Intentar filtrar todas las conexiones entrantes mediante un firewall, denegando el acceso a servicios cuya conexión desde el exterior no es necesaria. Si no disponemos de un firewall, más abajo hablo de IPTABLES.
- No instalar el entorno gráfico y mucho menos, ejecutarlo como root:
No tiene sentido tener las X en un servidor en producción. Si tenerlo arrancado de por sí ya es un agujero de seguridad y una fuente de inestabilidad del sistema, no hablemos de arrancarlo con el usuario root.
- Separación de particiones
Separar las particiones siempre es una buena idea. Tanto en lo que a seguridad se refiere, como a la hora de evitar que el disco se llene.
Lo ideal suele ser separar en particiones diferentes los directorios /var/, /home/, /usr/, /boot y /tmp.
- Fijar como Noexec las particiones que no vayan a necesitarlo, sobre todo /tmp
Una vez separadas las particiones, lo ideal es fijar (al menos) el directorio /tmp como noexec.
De esta forma, ante una posible intrusión, no se pueden ejecutar binarios desde /tmp, cosa bastante habitual cuando se intenta ejecutar código malicioso en un servidor.
- Revisar con frecuencia logs y gráficas de rendimiento.
Especialmente las gráficas de cpu y tráfico nos pueden ayudar a localizar comportamientos inapropiados, como un incremento de ancho de banda o de uso de cpu, que pudiera deberse a código malicioso, envíos de emails, shells, etc.
- cuidado con el comando Sudo, que lo carga el diablo:
Si puede ser, que no esté habilitado más que para lo estrictamente necesario.
Una entrada de este tipo en el fichero sudoers:
usuarioxx ALL=(ALL) ALL
puede suponer dar privilegios de root automaticamente al usuario que consiga el password de un usuario regular.
- Shell por defecto de usuarios que no necesiten loguearse:
Si existe un usuario en el sistema con el que vamos a ejecutar algún tipo de proceso, o que van a ser necesarios para conexiones via FTP, pero no van a necesitar loguearse en linea de comandos, podemos fijar su shell por defecto como /bin/false.
El usuario seguirá existiendo, podrá ser propietario de ficheros/directorios, podrá ingresar via FTP, pero jamás ejecutar una shell.
Para ello, editamos el fichero /etc/password, y en la linea donde están definidas las opciones de usuario, al final, definimos su shell como /bin/false:
usuarioFtp:x:3000:3000:,,,:/home/usuarioFtp:/bin/false
Permisos:
- chmod 777 está prohibido:
Nunca nunca nunca, hacer cambios de permiso a lo loco. hacer un chmod 777 sobre un fichero o un directorio está prohibido. Y más aun si se hace para solucionar algún problema de permisos que no sabemos como atajar.
Recomendaciones concretas en diferentes tipos de servicios:
SSh
- prohibir loguearse como root :
en el fichero de configuración (/etc/ssh/sshd_config), podemos deshabilitar la opción PermitRootLogin, fijandola en No:
PermitRootLogin no
De esta forma siempre tendremos que loguearnos como un usuario regular y escalar a root.
- Permitir el acceso sólo a los usuarios indicados
Al igual que para deshabilitar el login con el usuario root, podemos indicar qué usuarios podrán conectarse con la siguiente directiva en /etc/ssh/sshd_config:
AllowUsers mijack operador
De esta forma, permitimos solo al usuario mijack y al usuario operador ingresar en el sistema. Si hubiera más usuarios no podrían acceder via ssh.
Apache:
Uso de mod_secure:
- Para evitar inyecciones de código en nuestros sitios web, podemos activar el módulo mod_secure, que dispone de unas directivas por defecto muy completas que bloquearan URLS sospechosas. En ocasiones es demasiado restrictivo.
proteger con htpasswd
- Todo directorio o ruta sensible a ingresos de usuario no deseados o con contenido sensible, puede ser protegido mediante htpasswd. De esta forma al intentar acceder a una url concreta, nos pedirá user y password.
MySQL:
- Fijar siempre un password de root:
De no fijar un password de root para MySQL (por defecto vacio en muchas distribuciones de linux), cualquier usuario regular podrá loguearse en el sistema tecleando:
$ mysql -u root
- Cada bases de datos con su usuario y password:
Si existen varias bases de datos en nuestro sistema, es recomendable que cada una tenga un usuario y password de acceso. De forma que el usuario de una base de datos no pueda escribir en todas.
- Evitar conexiones externas.
Por defecto MySQL no admite conexiones externas puesto que solo escucha las peticiones desde localhost. Es preferible no cambiar esa configuración si no es necesario cien por cien.
Modo ultraparanoia:
- iptables:
iptables (antiguamente ipchains) es un framework inlcuido en el nucleo de linux que permite filtrar los paquetes de red, denegando o aceptando trafico dependiendo de multiples factores.
Si tenemos un nivel majo de paranoia, podemos configurar iptables para rechazar todo el tráfico que no se adapte al puramente necesario.
El funcionamiento de iptables es complejo puesto que también se puede usar para el enrutado de tráfico y nateo de puertos.
Ejemplo:
Rechazamos todo el tráfico por el puerto 22, y luego establecemos que solo aceptaremos el de una ip en concreto, xxx.xxx.xxx.xxx:
iptables -t filter -I INPUT -p tcp –dport 22 -j DROP
iptables -t filter -I INPUT -p tcp -s xxx.xxx.xxx.xxx –dport 22 -j ACCEPT
- SELinux (del inglés Security-Enhanced Linux, Seguridad Mejorada de Linux):
Creado a imagen y semejanza del control de acceso utilizado por el departamento de defensa de los Estados Unidos, SELinux implementa unas políticas de seguridad y controles de acceso extremadamente flexibles, con la posibilidad de ser a su vez, extemadamente paranoicas.
Algunas distribuciones, como CentOS, lo traen activado por defecto.
SELinux Permite el control total de usuarios, procesos archivos y sockets, de forma que según lo restrictivos que seamos al configurarlo, podemos impedir la ejecucion de servicios o binarios, el login de usuarios que no estén en la lista de permitidos o incluso la escritura en determinados directorios.
Seguiremos añadiendo cosas
Saludos.
MiJacK.
Comentarios recientes