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 ser
wikto 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?
Con la creación del espacio de trabajo para el usuario que se ha bautizado como IBM Cognos Business Insight
se proporciona al usuario de negocio una herramienta para poder
seleccionar objetos de diferentes componentes de la suite, e incluso
datos externos de ficheros, Excel, etc., para crearse sus propios
cuadros de mando interactivos con cualquier tipo de información que
maneja la herramienta. Puede utilizar informes de Report Studio, resultados analíticos de SPSS, previsiones de IBM Cognos TM1, o incluso datos locales.
