2 Tu Peor Enemigo: El Otro Admin

Sandino Araico Sanchez dentro de sus conferencias ha generado controversia dandoles el titulo del “Tu Peor Enemigo”, dentro de esta conferencia (que recomendamos mucho) intenta buscar los peores enemigos de un buen sistema y una buena seguridad de lo mismo.

Tomando el ejemplo de Sandino, daremos nosotros lo que se debe de hacer para
contrarrestar a “Tu Peor Enemigo”.

“Yo no he cambiado Nada” — Tu Peor Enemigo: El Otro Administrador.

Esta frase la he oido de clientes, administradores, estudiantes y hasta familiares: “Yo no he cambiado nada”, “Solo dejo de funcionar”, “De la nada ya no jala”,etc.

Esta frase es la peor frase que se puede oir sobre todo a altas horas de la noche o muy muy temprano en un dia de trabajo, ya que sabemos que habran cientos de llamadas de usuarios que no podran usar este servicio. Tuve yo un encuentro con el peor enemigo en una compañia a la que le daba servicio, siendo rarisimo que dejaran de usarse los servicios tuve que obviamente
ponerme a trabajar para detener a uno de los peores enemigos: “El Otro Administrador”

Obviamente restriccion de privilegios no funcionara ya que el tambien es administrador y el debe de tener privilegios para reiniciar servicios, hacer cambios requeridos, etc.

El problema entonces se refiere tanto a saber que se cambio, como a mantener una función que inhabilite los cambios en servicios que son criticos.

¿Cuales son los servicios criticos? En este caso era:

  • Servidor de Correo (Postfix)
  • Servidor de Web (Apache)
  • Servidor de base de datos (MySQL)

Ok entonces tenemos varios archivos que tienen la posibilidad de ser cambiados, teniendo asi un problema serio en los servicios, asi como el reinicio de los mismos y los logs.

Podemos tener aqui varias soluciones, la mas facil:

  • Instalar AIDE o algo parecido

El problema es que entonces el otro administrador va a querer administrar también nuestra base de datos de seguridad, lo cual nos deja no nada mas igual, si no peor.

Podemos crear rápidamente una base de datos con firmas md5 y tener un simple chequeo de cambios y que mande un correo con los cambios, ¿Como podemos crear una base de datos de ese tipo?

En una simple linea de comando:

find  -print | xargs md5sum > archivo_de_firmas.md5

Es decir, en nuestro ejemplo tenemos postfix:

find /etc/postfix -print | xargs md5sum > postfix_signatures.md5

Para Apache:

find /etc/apache2 -print | xargs md5sum > apache2_signatures.md5

En caso de que fuese apache.1.X.X:

find /etc/apache -print | xargs md5sum > apache_signatures.md5

o

find /etc/httpd -print | xargs md5sum > apache_signatures.md5

Teniendo ya esto podemos simplemente verificar las firmas dando el siguiente comando:

md5sum -c postfix_signatures.md5

lo cual nos daria un resultado de OK en caso de que las firmas fueran las
mismas.

¿Para que nos ayuda esto?, siendo md5 una firma del archivo cualquier cambio
que se le haga, aunque sea de una letra, un byte, cambiaria la firma dando asi
una veruficacion del cambio y nos puede dar una pista de donde estuvo el
cambio que genero el problema en realidad.

Un ejemplo con un directorio simple:

Obviamente esto puede ser incrementado hasta para un sistema operativo completo PERO hay que tomar en cuenta que cosas como los logs, utmp, wtmp, etc. cambian con el uso del servidor.Esto puede agregarse al crontab para que corra cada hora (o hasta cada 10 minutos si de verdad el enemigo es agil, rapido y con presteza para romper las cosas). Un ejemplo de crontab que corre cada 15 minutos y manda un correo con el output es:

#Poner SHELL y mandar correo con MAILTO
SHELL=/bin/sh
MAILTO=enrique.sanchez@security-dojo.com
#
# corre cada 15 minutos
*/15 * * * *       md5sum -c $HOME/fingerprints/apache2_fingerprints.md5

Podemos decir que hemos derrotado a nuestro enemigo, sin embargo tenemos otro problema, este es un remedio reactivo, el daño ya fue hecho y ahora tenemos que limpiar el problema. ¿Qué podemos hacer entonces?

El siguiente paso de defensa sobre nuestro peor enemigo: chattr

Este paso me sirvio muchisimo en una empresa donde todo el mundo movia cosas y “no movi nada” era la respuesta mas importante, sobre todo porque “el backend es tu problema no el mio”, en cuanto aplique la siguiente técnica el director
general supo rapidamente quienes movian las configuraciones, ya que se quejaron de que no podian hacerlo mas, siendo que “Nunca antes lo habian hecho” como ellos mismos dijeron.

chattr es una herramienta indispensable, que desgraciadamente no funciona en el sistema resiserfs (ya que reiser usa cosas mas complejas que ext2 y ext3) pero en ext2 y ext3 (que la mayoria de la gente usa) son excelentes.

La herramienta lsattr nos deja ver los atributos del archivo, el atributo que veremos por el momento es inmutable (i) si damos rapidamente un lsattr a httpd.conf podemos ver lo siguiente:

firebolt apache2 # lsattr httpd.conf
-------------- httpd.conf
firebolt apache2 #

Lo cual nos dice que no tiene ningun atributo por lo cual podemos editarlo de la siguiente manera:

firebolt apache2 # echo cambio >> httpd.conf
firebolt apache2 # tail -3 httpd.conf
# vim: ts=4 filetype=apache
cambio
firebolt apache2 #

Ahora hagamos el archivo inmutable, esto quiere decir que este atributo le
dice al sistema queu aun siendo root no puede modificarse, ni borrarse:

firebolt apache2 # chattr +i httpd.conf
firebolt apache2 # echo cambio >> httpd.conf
-bash: httpd.conf: Permission denied
firebolt apache2 # lsattr httpd.conf
----i--------- httpd.conf
firebolt apache2 #

¡EXCELENTE!

Ahora si queremo editarlo simplemente podemos remover el atributo de inmutable al archivo y podremos editarlo:

firebolt apache2 # chattr -i httpd.conf
firebolt apache2 # echo cambio2 >> httpd.conf
firebolt apache2 # lsattr httpd.conf
-------------- httpd.conf
firebolt apache2 # tail -3 httpd.conf
# vim: ts=4 filetype=apache
cambio
cambio2
firebolt apache2 #

El siguiente es un ejemplo de como usar chattr:

Estas dos técnicas son básicas para comenzar a detener al otro admin, la educación asi como la experiencia iran ayudando al otro admin para poder tener mejor control sobre su servidor (si es que quiere tener control de su servidor)Espero que con esto este peor enemigo pueda ser detenido al menos un poco.

2 comentarios hasta ahora.

  1. garaged el abril 23rd, 2008

    Muy buenos tips, yo creo que a todos nos pasa eso, y peor cuando la falla tiene que ver con algo que no está en tu poder, como cuando se les ocurre a los de windows poner un DNS extra :)

    Una cosa que yo utilizo en situaciones problemáticas es hacer un repositorio de subversion para los directorios “críticos” o “problemáticos”, me ayuda de 2 maneras, una es que puedo tener un historial, y la otra es que fácilmente encuentro los cambios con un simple “svn diff”, y pues en tres patadas le das al clavo, ni siquiera tengo que explorar el archivo que MD5 me dice que cambió.

    Obvio, me podrían dar en la mamá de diferentes maneras, pero es sorprendente que pocos administradores usan repositorios, y hasta ahora nunca se han dado cuenta de que está ahí, obvio tampoco es que tenga 15 años en el negocio :) (una solución simple es que el repo esté en un servidor tuyo de tu propiedad, que no puedan modificar, eso te cubre creo al 99.9%)

  2. nahual el abril 28th, 2008

    Ahhhh si .. subversion, fijate que no lo puse es un excelente ayudante no … igual puedes tambien ahcer rollback de lo que cambio el otro admin?

    Si siempre puedes tener repositorios de todo por otro lado, siempre y cuando recuerdes que cambios hiciste, tambien ayuda para cuando se esta desarrollando “como los hombres” en produccion.

    Excelente aportacion! gracias garaged!

Dejar un comentario