El rincón de JMACOE

Como llevo unos cuantos post filosóficos, vamos ahora con algo más técnico. 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.

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.

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

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.

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.

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 del 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.

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.

Chroot

Chroot es un entorno restringido para los usuarios. Digamos que un linux «mínimo» en el que ejecutamos nuestros programas. En principio, una forma muy eficiente de restringir los privilegios de un usuario, como pueda ser el del apache o una base de datos, pero en la práctica resulta un poco complicado de instalar y, sobre todo, de mantener.

Posiblemente el ejemplo más fácil de entender para chroot sea con vsftp, uno de los servidores FTP más seguros actualmente que corre bajo linux. Un usuario que haga loggin bajo chroot estará restringido a su home y no podrá navegar por los directorios y bajarse /etc/passwd, que es la metedura de pata típica al configurar un FTP bajo linux.

Para restringir un usuario en vsftp lo único que hace falta es editar vsftpd.conf y poner chroot_local_user=YES. Esto debería ser suficiente.

Dedicaremos un artículo a cómo configurar chroot para un entorno interesante, y no lo típico que uno se encuentra por la red, que es ftp o ssh.

Snort

Snort es un detector de intrusos que detecta ataques basado en patrones conocidos. Ya hemos hablado de él en numerosas ocasiones, por ejemplo aquí.

La instalación de snort y su actualización es totalmente trivial bajándose las reglas de emerging-threats, cosa que en su día explicamos en este post.

Snort tiene la ventaja de cazar eficientemente escaneos desde herramientas conocidas, como puedan serwikto o nmap, permitiendo además, combinado con otro HIDS como pueda ser ossec, bloquear la IP atacante al instante.

El problema con snort es que no se entera del tráfico que va por ssl … aparte de no servir para mucho detectando ataques sobre aplicaciones web.

HIDS/Integrity checkers

Otra parte importante de la seguridad en linux es tener un buen HIDS (Host Intrution Detection System). Entre ellos, personalmente, me gusta ossec, que corre tanto bajo linux como bajo windows.

Un HIDS tiene una serie de tareas encomendadas, como puedan ser:

– monitorizar cambios en archivos importantes de linux, como puedan ser /etc/passwd o los binarios del sistema.

– detectar, combinado con un sniffer de red, ataques desde otros HOSTs.

– controlar el uso de recursos en busca de posibles ataques por denegación de servicio.

– buscar posibles troyanos, rootkits, backdoors, …, malware en general que haya podido ser instalado por un usuario malicioso (vease la famosa herramienta chkrootkit).

– guardar los logs en un servidor remoto donde no puedan ser manipulados

[…]

El problema con los HIDS es que, hoy en día, la mayoría de veces que se entra en un servidor es vía la web y los ficheros que se modifican son los de la aplicación web. En una aplicación con varios miles de archivos asp no es fácil monitorizar la integridad.

Así pues, la instalación de HIDS en servidores, que no niego que sea necesario y que ofrezca «cierta» seguridad, realmente no significa mucho.

Modificación de banners

Otra de las cosas típicas que recomiendan en todos los libros de seguridad es modificar los banners de las aplicaciones (ftp, servidor de correo), para añadir un cierto grado de dificultad a la explotación del servicio.

Ciertos servicios, como puedan ser FTP o SSH, son muy fáciles de tocar. Por ejemplo, en vsftp tenemos la opción banner_file, que sirve exactamente para esto. Otros, como sendmail, requieren recompilar.

Este es un ejemplo de banner de POSTFIX modificado:

smtpd_banner = $myhostname ESMTP Sendmail 8.12.9

Con esto conseguiremos confundir a algunas herramientas típicas, como puedan ser nmap o amap. Pero un hacker no necesita para nada saber la versión exacta de servicio que corre … ¿acaso no es posible lanzar todos los exploits tanto para postfix como para sendmail «a ver si cuela»?

Hoy en día, al tener frameworks como metasploit, no supone ningún esfuerzo lanzar unas docenas de exploits en minutos. Así pues, la seguridad por oscuridad ayuda, pero desde luego muy poquito. No podemos confiar en cambiar los banners.

Seguramente podríamos hablar y hablar de otras medidas de seguridad «a la vieja usanza» que pueden adoptarse en un servidor linux, pero estas son suficientes para pasar al siguiente punto …

CONCLUSIONES

De acuerdo, podemos quitar paquetes innecesarios, minimizar los servicios que corren, instalar HIDS, snort, tener logs remotos, buscar backdoors y troyanos en el sistema, cambiar banners, poner los servicios en CHROOT, … Podemos hacer todo esto y más pero, ¿sirve para algo?

Todas estas medidas antes mencionadas son requisito de normas como PCI-DSS, que es obligatorio para manipular tarjetas de crédito, y, sin embargo, siguen robándose tarjetas de crédito. ¿Por qué?

La explicación es que hoy en día nadie tiene demasiado interés en instalar un troyano en un sistema o en intentar explotar una versión vieja de sendmail (cosa casi imposible en una entidad mínimamente importante). Las intrusiones vienen por la web, principalmente vía sql-injection en entornos LAMP, y los hackers no tienen ningún interés en añadir un usuario al sistema.

Lo que se busca es acceder a la base de datos y bajársela, nada más. No importa que sea un entorno chroot, ya que seguiremos podiendo hacer queries contra el mysql, que es realmente lo que necesitamos. Tampoco importa que vigilemos todo el tráfico de entrada en busca de patrones conocidos, puesto que en realidad este tráfico es muy fácil de confundir con tráfico legítimo. ¿Para que sirven los IDS/IPS?

La seguridad «tradicional» a muerto. Hoy en día lo realmente importante es securizar a nivel de aplicación.¿Afrontamos el problema o lo seguimos ignorando?