UN REPASO A LA SEGURIDAD DE LOS SERVIDORES LINUX – PARTE I

Jan 29th, 2010 | Posted by | Filed under Linux, Redes, Seguridad

Vamos a darle un pequeño repaso a algunas medidas de seguridad básicas para un linux y a su aplicación real hoy en día. Como veremos, muchas de las cosas que se venden como “seguridad en servidores linux”, han quedado obsoletas y no sirven para mucho.

Empezaremos por repasar algunos conceptos de los de toda la vida, como la búsqueda de ficheros setuidados y la deshabilitación de servicios innecesarios. Tras esto, le daremos un repaso a la importancia actual de estas medidas de seguridad en un entorno corporativo actual. Finalmente, hablaremos de las nuevas tendencias en seguridad.

(1) Puntos de montaje

Por defecto, FEDORA va a permitir la ejecución de archivos en /tmp/. Esto no es que sea muy grave, pero lo ideal sería montar /tmp en una partición aparte teniendo cuidado de ponerle los permisos adecuados:

/dev/sda4 /tmp ext3 defaults,nodev,noexec,nosuid 1,2

Que le dice a linux que no puedan crearse dispositvos, ni ejecutables ni archivos setuidados. Hoy en día, también hay que decirlo en honor a la verdad, estas cosas han quedado un tanto obsoletas. La seguridad de servidores se centra en las aplicaciones web y las bases de datos, y no en esto.

(2) buscar archivos con el suid y el sguid

La búsqueda la hacemos así: find / \(-perm -4000 -o -perm 2000 \) -type f -exec ls {} \;

En la salida, podemos ver que algunos de estos archivos no necesitan estos permisos especiales puestos, por ejemplo:

-rwsr-xr-x 1 root root 47524 2009-12-15 14:43 /bin/umount
-rwsr-xr-x 1 root root 70348 2009-12-15 14:43 /bin/mount
-rwsr-xr-x 1 root root 36876 2009-07-26 14:22 /bin/ping6
-rwsr-xr-x 1 root root 42072 2009-07-26 14:22 /bin/ping

(3) Permisos laxos en directorios

Debemos buscar todos los directorios que tengan permiso de escritura demasiado laxo, por ejemplo directorios con un rw para todos, y que no tengan el sticky bit. Si nos fijamos, /tmp tiene dicho bit, que sirve para que cada usuario sea propietario de sus archivos, aunque todos los usuarios tengan permiso de escritura en el directorio.

ll /|grep tmp
drwxrwxrwt 10 root root 4.0K 2010-01-27 16:35 tmp/

Podemos hacer la búsqueda de archivos con permisos de escritura para “otros” y “todos” con este comando:

find / -type d \( -perm -g+w -o -perm -o+w \) -not -perm -a+t -exec ls -lad {} \;
Cuando obtenemos un directorio con estos permisos, por ejemplo el de debajo, deberemos buscar qué usuarios están en el grupo al que pertenece el archivo y ver que es correcto confiar en que puedan escribir:

drwxrwxr-x 3 root lp 4096 2010-01-20 11:48 /var/cache/cups

En este caso, no pasa nada ya que el grupo es el usuario que se usa para imprimir, lp.

En linux es posible controlar de forma mucho más granular los permisos de los archivos usando ACLs, pero la realidad es que resulta algo incómodo de administrar cuando tienes muchos usuarios y, por lo tanto, se acaba tirando por la calle de en medio y creando unos pocos grupos en los que acaba todo el mundo.

Tipicamente, un servidor linux que tenga una aplicación corriendo de la propia empresa va a tener directorios con los permisos mal puestos. En lugar de perder nuestro tiempo buscando fallos en el sistema operativo que son muy difíciles de explotar, como lo pueda ser que el binario ping esté setuidado, es siempre mejor ir a estos directorios de la empresa e intentar sacar información útil de ellos. Seguramente encontraremos scripts ejecutados por root y con permisos 777. Es cuestión de tiempo.

(4) logs

Lo ideal es guardar todos los logs en un servidor remoto. Pero, si esto no se hace, al menos pueden ponerse los archivos de logs como “only append”, así:

chattr +a /var/log/secure

Lo que nunca dicen en los libros, es que la rotación de logs FALLA si se hace esto. En principio parece una tontería, porque /var/log/secure tampoco ocupa tanto, pero si hacemos esto con los logs de, por ejemplo, el apache tendremos que tener cuidado de incluir en nuestros scripts las correspondientes instrucciones para quitar el +a y volverlo a poner al final.

También existe la posibilidad de hacer que sea imposible quitar el +a sin reiniciar el servidor. Para ello hay que modificar CAP_LINUX_IMMUTABLE. Puedes leer más sobre esto, por ejemplo, en este link

De todas formas, no me cansaré de insistir en que lo mejor es guardar los logs en un servidor remoto.

(5) Permisos mínimos para cada usuario

Seguramente tendremos unos cuantos usuarios que lleven distintos componentes del servidor, por ejemplo podríamos tener uno para administrar el apache y otro para la base de datos. Pues bien, hay que intentar restringir lo más posible lo que puede hacer cada usuario. Para esto, contamos con sudo.

Por ejemplo, imaginemos que el usuario pepe necesita hacer un backup de el directorio etc. En este caso, lo que haremos será incluir una linea en /etc/sudoers conteniendo exactamente el comando del backup, con todos sus parámetros.

No me meto en describir cómo funciona esto porque hay información de sobras en internet, por ejemplo.

(6) Quitar servicios innecesarios

Deberemos ver qué servicios corren en la máquina y eliminar aquellos innecesarios. En particular, con netstat -nlp veremos qué programas están escuchando en qué puertos, lo cual permite deshabilitar aquellos que no consideremos oportunos.

Por ejemplo, seguramente querrás quitar ip6tables (salvo que tengas ipv6, que no creo), cups (salvo que des servicios de impresión), …

netstat -nlp|grep 631|grep -v 127.0.0.1
udp 0 0 0.0.0.0:631 0.0.0.0:* 864/cupsd

En Fedora, RedHat y similares, con setup accedemos a habilitar/deshabilitar servicios.

Muchas veces los admins se saltan este paso porque hay un firewall que corta todos los servicios que no escuchan, lo cual está muy bien, pero no debemos olvidar que el hecho de tener un servicio escuchando innecesariamente puede abrirnos las puertas a nuevos ataques, aunque hoy en día esto es un tanto improbable.

(7) Chroot

(to be continued …)

Fuente |  Auditoria en Redes para Empresas

Share
Comments are closed.