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.