Reforzando la instalación de Debian GNU/Linux

Transcripción

1 ArCERT Coordinación de Emergencias en Redes Teleinformáticas versión de marzo de 2006 Resumen En este documento describiremos como mejorar la seguridad en una instalación de GNU/Linux. El temario incluye configuración adecuada del BIOS, particionamiento, instalación minima, deshabilitación de servicios no utilizados, desinstalación de software no utilizado, revisión de logs, detección de intrusiones, firewall de host, actualizaciones de seguridad, sincronización de hora, etc. Utilizaremos como base la distribución Debian, versión Sarge (o stable). Muchos de los conceptos vertidos en esta guía podrán ser aplicados a cualquier distribución de Linux, o sistema operativo tipo Unix (*BSD, Solaris, etc.). En ningún caso podrá responsabilizarse a ArCERT o a la ONTI en forma institucional, o a sus agentes a título individual y/o personal, de ningún daño puntual ni general, directo o indirecto, consecuencial o incidental, o de cualesquiera otra categorías, derivado de la ejecución de las actividades planteadas para este tutorial.

2 Índice 1. Introducción 3 2. Pre-Instalación 3 3. Instalación Particiones El usuario normal Boot Loader 6 5. Limpieza Servicios de red innecesarios Otros paquetes no utilizados Módulos de Kernel Deshabilitando el CTRL-ALT-Del Opciones de Montaje Usuarios y permisos Usuarios con shell interactívo El bit SUID Permisos de tareas planificadas Sudo Limitación del acceso de root El grupo wheel La consola física Acceso vía SSH Administración Remota Parámetros del kernel Selección de paquetes Firewall Actualizaciones de seguridad Mantenimiento Sincronización horaria Back-up Auditorías regulares Chequeos de integridad Manejo de bitácoras (logs) Herramientas para automatizar el fortalecimiento Bastille Linux Paquetes Harden Otras fuentes de información CheckList ArCERT c 2006

3 1. Introducción Por qué necesitamos reforzar la instalación de un sistema operativo? Salvo raras excepciones 1, los sistemas operativos en general no dedican un gran esfuerzo en la seguridad al momento de la instalación. Y cuál es el resultado de este hecho? Con el crecimiento que ha tenido Internet en los últimos años, la ventana de tiempo entre que un sistema operativo recién instalado (sin parches) se conecta a Internet, y que el mismo sufre una intrusión, ha bajado de días a mediados de los 90, a horas en el 2000, y minutos en la actualidad. En este documento nos ocuparemos de mejorar la seguridad en una instalación de GNU/Linux. Utilizaremos como base la distribución Debian, versión Sarge (o stable), por ser una de las más usadas en ambientes de servidor, y porque la consideramos como una de las más adecuadas para esa misma función. Muchos de los conceptos vertidos en esta guía podrán ser aplicados a cualquier distribución de Linux, o sistema operativo tipo Unix (*BSD, Solaris, etc.). Sin embargo, se deberán tomar los recaudos necesarios para que dicha adaptación no deje puertas abiertas debido a las diferencias entre las distintas distribuciones. 2. Pre-Instalación Comenzaremos por considerar dos temas esenciales. Se dice que quien tiene acceso físico a un equipo tendrá acceso total al mismo. Si bien ésta afirmación no siempre es exacta, y algunas de las tareas que realizaremos tienen por objetivo contrarrestarla, es absolutamente recomendable que el acceso físico al servidor y su consola esté restringido sólo al personal autorizado. Como segundo recaudo, el equipo no deberá conectarse a la red hasta haber finalizado con las tareas de aseguramiento. En caso de ser necesario algún tipo de conexión (como ser que el equipo debe iniciarse mediante netboot), estas tareas deberán realizarse en una red cerrada, asegurada, y preferentemente aislada. Antes de realizar la instalación del sistema operativo elegido, hay algunas tareas que podemos realizar. En particular, mediante la configuración del BIOS del equipo en cuestión, podremos restringir algunos puntos de entrada que no sean necesarios para la operatoria normal del sistema. Entre otros, podemos nombrar los siguientes. Puertos paralelos Puertos seriales Puertos USB Disqueteras Lectoras de CD/DVD En la Figura 1 podemos observar un ejemplo de cómo se deshabilitan algunos puertos innecesarios en el BIOS. Otra tarea importante consiste en configurar el orden de selección de dispositivos para el boot del equipo. Para poder realizar la instalación, deberemos seleccionar el medio disponible para la misma, normalmente CD-ROM, pero una vez finalizada la misma, deberemos seleccionar únicamente el disco de arranque del sistema. En caso de no ser posible, como en el ejemplo de la Figura 2, deberemos ordenar los dispositivos para que el elegido sea el primero de la lista. Inclusive podemos deshabilitar todos los dispositivos de almacenamiento menos el dispositivo de boot. Por ejemplo, una vez instalado el sistema operativo, se puede deshabilitar el CD-ROM del BIOS, ya que el mismo será detectado de todas maneras por el sistema operativo. Por último, deberemos configurar una contraseña para restringir la realización de cambios en la configuración del BIOS. 3. Instalación Para realizar un buen proceso de aseguramiento de un servidor GNU/Linux Debian, incluiremos su instalación. Durante el proceso de instalación, cuya descripción completa puede encontrarse en la bibliografía, deberemos tener en cuenta algunos detalles que nos permitirán asegurar un resultado exitoso. 1 Por ejemplo, OpenBSD ArCERT c 2006

4 Figura 1: Deshabilitación de puertos y periféricos Figura 2: Deshabilitación de puertos y periféricos 4 ArCERT c 2006

5 Figura 3: Opciones de montaje durante la instalación 3.1. Particiones En primer lugar, deberemos diseñar cuidadosamente el sistema de archivos. No existe una regla general, pero podemos seguir algunos consejos para mejorar tanto la seguridad como el rendimiento. Algunos de estos consejos consisten en: Si el sistema va a alojar múltiples usuarios interactivos, /home debería tener su propia partición. En equipos que brinden servicios críticos, /var/log podría llenarse y perjudicar el buen funcionamiento de los mismos, por lo que podría separarse en otra partición. Por esta misma razón, /tmp utilizará una partición separada. En general, /var (pensado para todas las operaciones más dinámicas) y /usr (donde normalmente se alojan los archivos menos susceptibles a cambios) tendrán su propio espacio. Las particiones pueden montarse con ciertas opciones que restringen su funcionalidad (ver Figura 3). Las restricciones más interesantes que pueden aplicarse en el momento de la instalación son (hablaremos más tarde sobre esto en Opciones de Montaje ): nodev: No permite la creación de dispositivos (devices). nosuid: No permite la utilización de los bits suid y sgid. noexec: No permite la ejecución de archivos En general, podemos definir que: En ninguna partición, salvo / (o donde resida /dev), se necesitan dispositivos. /, /usr y /var, en general, son las únicas particiones desde las cuales se debería poder ejecutar archivos. Además, sólo /usr y /var pueden necesitar el uso de suid. Estas restricciones pueden y suelen variar según las diferentes distribuciones de GNU/Linux. 5 ArCERT c 2006

6 Figura 4: Esquema de particiones que propuesto para Multi-user workstation En algunos casos puede ser recomendable montar /usr como ro (sólo lectura), pero habilitar esta opción durante la instalación hará que ésta sea imposible de realizarse, ya que habrá que escribir en dicha partición. Evitar la ejecución de binarios en /tmp con la opción noexec es una buena idea. Pero hay que tener en cuenta que, en algunos casos, Debian ejecutará ahí algunas acciones cuando instala paquetes. En nuestro ejemplo usaremos el esquema de la Figura 4, que es la distribución propuesta por Debian para Multi-user workstation (estación de trabajo multiusuario) El usuario normal Como veremos más adelante(véase también Limitación del acceso de root ), el acceso al sistema como usuario root estará muy restringido, por lo que la instalación es el momento correcto para la creación de, al menos, un usuario no privilegiado. En nuestro ejemplo usaremos operador, tal como se ve en la Figura 5. Se debe evitar la existencia de cuentas impersonales, por lo que el campo full-name (nombre completo) puede sernos de utilidad. El usuario no privilegiado, además de darnos el acceso inicial al sistema, nos permitirá realizar todas aquellas tareas que no requieran extricamente capacidades de root. Una vez terminada la instalación del sistema operativo base, comenzaremos el fortalecimiento propiamente dicho del sistema. Si aún no modificó el orden de boot en el BIOS, este el momento. 4. Boot Loader Vamos a asegurar el boot loader, en nuestro caso el grub, que es el programa encargado de cargar el kernel en memoria y ejecutarlo. Para evitar que alguien con acceso físico a la consola de nuestro equipo (situación que deber ser evitada a toda costa) pueda modificar los parámetros de inicialización del kernel, protegeremos el boot loader contra modificaciones. Primero, generaremos un hash del pasword que utilizaremos: 6 ArCERT c 2006

7 Figura 5: Creación de un usuario no privilegiado debian: # grub-md5-crypt Password: Retype password: $1$1nxTK1$0kdd0C8txj7nDPx5SnVx./ Una vez obtenido el hash, procederemos a insertarlo en la siguiente línea en el archivo /boot/grub/menu.lst: ## password [ --md5 ] passwd # e.g. password topsecret # password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/ # password topsecret password --md5 $1$1nxTK1$0kdd0C8txj7nDPx5SnVx./ En este mismo archivo, editaremos el valor de la variable lockalternative, para que el password que acabamos de crear no sólo se aplique a las modificaciones explícitas de los parámetros de inicio del kernel, sino que además sea necesaria para iniciar el sistema en modo single user, también conocido como Recovery Mode. ## should update-grub lock alternative automagic boot options ## e.g. lockalternative=true ## lockalternative=false # lockalternative=true Por otro lado, hay que modificar los permisos de /boot/grub/menu.lst para evitar que los usuarios no privilegiados accedan al hash: debian: # chmod o-r /boot/grub/menu.lst Para completar este proceso, deberemos ejecutar el comando update-grub y así hacer efectivo el cambio del lockalternative: debian: # update-grub Searching for GRUB installation directory... found: /boot/grub. Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst. Found kernel: /boot/vmlinuz Updating /boot/grub/menu.lst... done 7 ArCERT c 2006

8 5. Limpieza Para continuar con la configuración del equipo vamos a minimizar la instalación, desintalando paquetes que no se utilicen, cerrando servicios de red, y optimizando la carga de módulos del kernel Servicios de red innecesarios Muchas distribuciones instalan servicios que abren puertos de red. Debian Sarge (no así versiones anteriores) instala pocos de estos, por lo que no nos atendremos al ejemplo. Para ver que procesos levantan puertos podemos correr el comando netstat -tulp: debian: # netstat -tulp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 *:time *:* LISTEN 608/inetd tcp 0 0 *:discard *:* LISTEN 608/inetd tcp 0 0 *:daytime *:* LISTEN 608/inetd tcp 0 0 localhost:smtp *:* LISTEN 602/exim4 udp 0 0 *:discard *:* 608/inetd udp 0 0 *:bootpc *:* 708/dhclient debian: # Como podemos observar, los servicios time, discard y daytime se encuentran habilitados y levantados vía inetd. Para deshabilitarlos, procederemos a editar el archivo /etc/inetd.conf, y comentar las líneas correspondientes. Los cambios se producirán al reiniciar el servicio. debian: # /etc/init.d/inetd restart Restarting internet superserver: inetd. Por otra parte existen servicios no levantados por inetd que seguramente podremos eliminar (aunque esté escuchando sólo en localhost), como el caso de exim4 si no necesitamos un MTA 2 : apt-get remove --purge exim4-config exim4-base Esto borrará la configuración y los paquetes relacionados con exim4, así como sus dependencias reversas. Por último, bootpc corresponde al cliente DHCP. No se aconseja que los servidores obtengan su configuración de red vía DHCP. Puede borrarse eliminando el paquete dhcp-client. Así se debe proceder con cada uno de los servicios de red que tenga el sistema y que no sean necesarios Otros paquetes no utilizados La instalación base de cualquier sistema operativo instala una serie de paquetes que, si bien son utilizados en la mayoría de los casos, no siempre son totalmente necesarios. Podemos ver todos los paquetes instalados en nuestro sistema así: dpkg -l more Esto mostrará una larga lista (paginada con more) con el nombre del paquete, su versión y una breve descripción, tal como se ve en la Figura 6. Como verán, los paquetes son muchos y muy variados. Deberemos utilizar nuestra experiencia e imaginación para detectar los paquetes innecesarios de esta larga lista, siguiendo algunas reglas de sentido común. Por ejemplo: Si sólo vamos a utilizar ethernet, todos los paquetes que tengan que ver con PPP 3 no serán necesarios (ppp, pppconfig, pppoe, pppoeconf). En general, los paquetes de internacionalización son innecesarios (locales). 2 Mail Transport Agent (Agente de Transporte de Correos). Sistema para envio de correo electronico 3 Point-to-Point Protocol (Protocolo punto a punto) 8 ArCERT c 2006

9 Figura 6: Listado de los paquetes instalados (dpkg -l) Los paquetes para desarrollo como los compiladores o intérpretes (perl, gcc) y las bibliotecas terminadas en -dev sólo son utilizados en casos particulares, por lo que pueden borrarse. La automatización de detección de hardware nomalmente no es necesaria, y hasta puede ser perjudicial (hotplug, discover1-data). En caso de desinstalarlos, tendremos que prestar particular atención a la subsección Módulos de Kernel. Los paquetes relacionados con dispositivos que no tenemos o no utilizamos son prescindibles (usbutils, eject, setserial, fdutils) Los programas que no utilizamos pueden borrarse (aptitude, info, ipchains, mailx, nano, telnet, makedev) Las bibliotecas usadas por los paquetes que borramos tampoco son necesarias (libdiscover1,libusb). Para identificar estas bibliotecas nos puede ser de utilidad un paquete llamado deborphan 4. Un punto importante es evitar borrar paquetes de tipo essential. Estos paquetes son, por lo general, necesarios para el correcto funcionamiento del sistema operativo y requieren una confirmación particular. Puede ocurrir que encontremos archivos de los que desconocemos el paquete que los instaló. Para esto puede ser útil el comando dpkg -S. Por ejemplo, el archivo /usr/bin/e2pall pertenece al paquete tetex-bin: debian: # dpkg -S /usr/bin/e2pall tetex-bin: /usr/bin/e2pall Una mención especial merece el paquete gcc-3.3-base, que sólo contiene documentación descriptiva y se incluye únicamente por razones de dependencias de paquetes, por lo que puede ser conservado sin mayores problemas. El siguiente paso será desinstalar los paquetes seleccionados. Para ello, utilizaremos el siguiente comando: debian: # apt-get remove --purge aptitude dhcp-client [...] Así se eliminará tanto los paquetes como sus archivos de configuración, esto último gracias al modificador --purge. Estemos atentos a la lista de paquetes que realmente se van a remover ya que también se borran aquellas dependencias reversas de los paquetes definidos. De esta manera, reducimos la cantidad de programas instalados en nuestro sistema, lo que se traduce en una menor probabilidad de vernos afectados por algún bug ArCERT c 2006

10 Figura 7: Listado de los módulos cargados (lsmod) 5.3. Módulos de Kernel Los módulos le dan flexibilidad al kernel, levantando drivers sin necesidad de reinicios. Evitar levantar aquellos módulos que no utilizemos puede, además de evitar los efectos de sus bugs, incrementar la velocidad de arranque. Las aplicaciones de detección automática de hardware cargan módulos en forma dinámica cuando son necesarios. Para ver los que están actualmente cargados en el sistema puede emplear el comando lsmod y obtendrá un resultado semejante al de la Figura 7. Recordemos que en la subseccion Otros paquetes no utilizados se propuso eliminar todos los paquetes que detectan hardware, como discover1, por lo que tendremos que forzar la carga de los drivers que utiliza nuestro hardware para funcionar y que antes se detectaban automáticamente. Para esto necesitaremos editar el archivo /etc/modules. Aquí podremos agregar los módulo que necesitemos levantar (la placa de red, por ejemplo) y eliminar aquellos que no sean necesarios, como ide-cd y psmouse. En nuestro ejemplo el archivo quedaría así, siendo pcnet32 el driver de la placa de red: ide-disk ide-generic pcnet32 Para cerciorarnos de que se levanta todo lo necesario al arrancar, podemos reiniciar el sistema y comprobarlo. Hay que tener en cuenta que existen muchas aplicaciones que levantan módulos por demanda. Por ejemplo ipv6, que es el soporte para IP versión 6, puede ser levantado por demonios que intenten escuchar en una intefaz IPv6. Este es el caso de SSH que por defecto levantará con este soporte. Para evitar esto puede configurar estas aplicaciones para que sólo utilizen IPv4, o bien, eliminar la posibilidad que el módulo ipv6 se cargue. Ésto último se consigue realizando la siguente modificación en /etc/modprobe.d/aliases: #alias net-pf-10 ipv6 alias net-pf-10 off 6. Deshabilitando el CTRL-ALT-Del Este método de reinicializar el equipo siempre ha sido útil y atractivo en GNU/Linux, pero posiblemente no queremos que cualquiera con acceso a la consola puede utilizarlo. Vamos a deshabilitarlo comentando la línea correspondiente en el archivo /etc/inittab: 10 ArCERT c 2006

11 # What to do when CTRL-ALT-DEL is pressed. #ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now Sólo resta avisarle al proceso init que debe releer el archivo de configuración: debian: # telinit q O su equivalente, debian: # kill Opciones de Montaje Las particiones realizadas en la seccion Instalación nos permiten montar los sistemas de archivos con distintas opciones, algunas de las cuales vimos en aquel apartado. La lista de particiones a montar se encuentra en /etc/fstab. Si seleccionamos las opciones de nodev, nosuid y noexec durante la instalación el archivo quedará algo así: # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 /dev/sda1 / ext3 nosuid,errors=remount-ro 0 1 /dev/sda8 /home ext3 nodev,nosuid,noexec 0 2 /dev/sda7 /tmp ext3 nodev,nosuid 0 2 /dev/sda5 /usr ext3 nodev 0 2 /dev/sda6 /var ext3 nodev 0 2 /dev/sda9 none swap sw 0 0 /dev/hdc /media/cdrom0 iso9660 ro,user,noauto 0 0 /dev/fd0 /media/floppy0 auto rw,user,noauto 0 0 Si no utilizaremos el CD-ROM o la disquetera, podemos eliminar las últimas dos líneas de este archivo. Pero si decidimos conservar alguna de las dos, al menos deberemos eliminar la opción user, que cumple la función de permitir a un usuario no privilegiado montar y desmontar dicho dispositivo. Otras opciones útiles pueden ser (para más información, man mount): sync: Todas las operaciones de I/O 5 se hace de forma sincrónica. defaults: Son las opciones por defecto, es decir: rw, suid, dev, exec, auto, nouser, y async. auto: Monta el sistema de archivos al inicio. 8. Usuarios y permisos 8.1. Usuarios con shell interactívo Comenzaremos por revisar los usuarios creados durante el proceso de instalación. Para esto tenemos que analizar el archivo /etc/passwd, como se ve en la Figura 8. Como podemos observar, existen varios usuarios, todos considerados del sistema (en el caso de Debian, se caracterizan por tener un user id menor que 1000), que poseen como shell a /bin/sh, siendo esto totalmente innecesario dado que ninguno de estos usuarios será utilizado de manera interactiva. Utilizaremos el siguiente comando para modificar esta situación: debian: # chsh -s /bin/false daemon Y así para cada uno de los usuarios no interactivos; en este caso root y operador son la obvia excepción. El comando /bin/false siempre devuelve error y evita el login. 5 Input/Output (operaciones de Entrada/Salida) 11 ArCERT c 2006

12 Figura 8: Usuarios del sistema (/etc/passwd) 8.2. El bit SUID Vamos a revisar algunos permisos importantes en los archivos. Uno de los principales peligros que encontramos en los permisos de los archivos ejecutables es el suid bit, que permite a cualquier usuario que tenga permiso de ejecución sobre este archivo, ejecutarlo como si realmente fuese el usuario dueño del archivo, en lugar de él mismo. Un problema muy común, es que un programa comúnmente utilizado por los usuarios tenga como dueño a root, y tenga prendido el bit suid. Si este programa llegase a tener un bug, por ejemplo un buffer overflow o un stack overflow, podría llegar a convertirse en la herramienta que necesita un posible atacante que haya logrado ingresar al sistema para convertirse en root. También existe el bit guid que es lo mismo, pero aplicado al grupo. Los archivos con este permiso pueden ser encontrados así (Figura 9): debian: # find / -path /proc -prune -o -type f -perm ls De toda la lista de archivos con este particular permiso sólo son totalmente necesarios algunos de ellos: passwd: para que los usuarios puedan cambiar su password. exim4: para el correcto funcionamiento del interno, si es que decidimos no borrarlo del sistema. login: para que los usuarios puedan ingresar al sistema. unix chkpwd: se utiliza para que los programas puedan verificar el password ingresado por el usuario, sin la necesidad de tener cada uno el bit suid. su: para que usuarios no privilegiados puedan convertirse en root. Para el resto de los programas no es extrictamente necesario este permiso, salvo en casos particulares en los que habrá que evaluar los beneficios y desventajas (por ejemplo, el uso de crontabs por parte de los usuarios). Para el resto: debian: # chmod ug-s /usr/bin/wall /usr/bin/newgrp /usr/bin/chsh [...] 8.3. Permisos de tareas planificadas Si bien ya anteriormente le sacamos el bit suid al programa crontab, no estará de más restringir qué usuarios pueden tener acceso a su uso. Para esto debemos crear el archivo /etc/cron.allow con una única línea: 12 ArCERT c 2006

13 Figura 9: Archivos con el bit suid y guid (find / -path /proc -prune -o -type f -perm ls) root Si este archivo existe, sólo los que estén listado en él podrán usar cron. El comando at, utilizado para la ejecución diferida de tareas, es un caso muy similar al de cron. El archivo /etc/at.allow se utiliza limitar su uso y su funcionamiento es identico a /etc/cron.allow Sudo Una herramienta que permite tener un control mucho más estricto sobre las tareas que realizan los usuarios que requieran privilegios administrativos es sudo. Con esta herramienta podremos configurar, entre otras cosas: Qué usuarios pueden elevar sus privilegios (o simplemente ejecutar acciones como otros usuarios). Qué tareas pueden realizar. Si necesitan ingresar un password, y si es el suyo propio o el del usuario impersonado. Restricciones horarias. Lugar desde donde está conectado el usuario. Registro de las acciones realizadas. Sudo es una herramienta versátil y bien documentada. Se puede encontrar más ejemplos y detallada información en la página principal de sudo Limitación del acceso de root La idea es evitar el login directo de root. Es decir, para acceder al sistema tendremos que ingresar como un usuario no privilegiado y después convertirnos en root mediante el comando su. Además sería interesante restringir los usuarios que podrán transformarse en superusuario ArCERT c 2006

14 9.1. El grupo wheel Existe una forma de limitar qué usuarios pueden ejecutar el comando su. Para esto debemos editar el archivo /etc/pam.d/su y habilitar la siguiente opción: # before they can use su. You can also add "group=foo" to # to the end of this line if you want to use a group other # than the default "root". # (Replaces the SU_WHEEL_ONLY option from login.defs) auth required pam_wheel.so Ahora sólo los usuarios que pertenezcan al grupo wheel podrán utilizar el comando su. No debemos olvidarnos de crear el grupo y agregar los usuarios necesarios al mismo: debian: # addgroup --system wheel Adding group wheel (104)... Hecho. debian: # usermod -G wheel operador 9.2. La consola física Esta es otra forma de mitigar una falencia en el acceso físico al servidor. Se puede evitar que root acceda directamente por una consola física al sistema. En el archivo /etc/securetty tenemos la lista de consolas en las que root puede loguearse. Podemos simplemente comentar dichas lineas y así restringir el acceso Acceso vía SSH Si en nuestro sistema está instalado SSH como forma de administración remota (véase también Administración Remota ), también debemos limitar el acceso directo de root. Para lograrlo hay que editar el archivo de configuración de ssh en /etc/ssh/sshd config: PermitRootLogin no Recordemos que hay que reiniciar el servicio de SSH para que esto tenga efecto. debian: # /etc/init.d/ssh restart De esta manera, para acceder remotamente al equipo deberemos utilizar algún otro usuario. 10. Administración Remota Vamos a suponer que es necesario acceder remotamente al equipo para su administración. Seguramente el protocolo elegido será SSH 7. Habrá que instalar OpenSSH, que en la versión Sarge de Debian viene el servidor junto con el cliente. debian: # apt-get install ssh Durante su instalación, deberemos responder algunas preguntas. La primera es sobre la versión de SSH a ejecutar. Elegimos sólo permitir la versión 2 del protocolo, ya que las versiones anteriores tienen importantes defectos de diseño que pueden comprometer la seguridad del equipo. La siguiente pregunta nos consulta sobre el bit suid en el programa ssh-keysign. Por un lado, no utilizaremos el método de autenticación basada en host, y por otro, intentamos evitar el uso de este bit, por lo que elegimos la opción no. La última pregunta es sobre si queremos iniciar el servidor de SSH. Será conveniente restringir desde dónde se puede acceder a dicho protocolo. Más allá del uso de un firewall lo haremos vía tcpwrapper, soportado por OpenSSH. Usaremos la política todo denegado excepto lo expresamente permitido. En el archivo /etc/hosts.deny: 7 Secure SHell: Protocolo que brinda, entre otras cosas, acceso remoto seguro a un shell 14 ArCERT c 2006

15 sshd : ALL Y en /etc/hosts.allow, las IPs o redes de las cuales permitimos el acceso: sshd : /24 Este método también puede utilizarse con cualquier servicio que utilice la librería libwrap (hoy incluida en la libc), o mediante la utilización del programa tcpd. 11. Parámetros del kernel El kernel es configurable desde /etc/sysctl.conf, donde se pueden ajustar varios parámetros. Veamos algunos de ellos 8 : # Ignorar el uso de la tecla "Petición de sistema" kernel.sysrq=0 # Normalmente, no hay razón para utilizar broadcasts ICMP net.ipv4.icmp_echo_ignore_broadcasts=1 # Tampoco debemos hacerle caso a respuestas ICMP que no # pedimos net.ipv4.icmp_ignore_bogus_error_responses=1 # Los ICMP redirects son necesarios en escasas # excepciones (por ejemplo, cuando hay 2 gateways) net.ipv4.conf.all.accept_redirects=0 net.ipv4.conf.default.accept_redirects=0 # Tampoco aceptamos paquetes con "source route" net.ipv4.conf.all.accept_source_route=0 net.ipv4.conf.default.accept_source_route=0 Y para hacer efectivos los cambios inmediatamente: debian: # sysctl -p 12. Selección de paquetes En esta etapa debemos tener en especial consideración que fines va a cumplir el equipo, y seleccionar el software a instalar en consecuencia. La principal sugerencia para esta etapa consiste en instalar únicamente el software estrictamente necesario. Por ejemplo, en este caso utilizaremos el equipo como servidor Web. Que tipo de servidor Web? Supongamos que sólo necesitamos un servidor Web con páginas estáticas. Es necesario instalar un Apache con PHP? La respuesta claramente es no. De hecho no sólo no vamos a necesitar PHP, sino que posiblemente ni siquiera sea Apache la mejor opción. Veamos algunos puntos a tener en cuenta para elegir una aplicación: Mientras menos cosas extra tenga la aplicación, mejor. Siguiendo con el ejemplo de un servidor de web de páginas estáticas, existen alternativas como thttpd (que tiene soporte para CGI 9 ) o dhttpd. Programas más chicos suponen menos líneas de código donde existe una probablididad menor de que alla bugs. Priorizemos las aplicaciones de red que puedan ser enjauladas fácilmente dentro de un chroot. Hay que tener en cuenta que tan mantenido está el programa. Se puede consultar en foros y listas en busca de opiniones. En el caso de Debian podemos visitar del paquete> para ver cada cuanto hay nuevas versiones y sus bugs. La escalabilidad debe ajustarse a nuestras necesidades de crecimiento. Si prevemos aumentar la carga de una aplicación en un futuro cercano ésta debe soportarla de antemano. 8 Puede encontrar otros parámetros en 9 Common Gateway Interface (Pasarela de Interfaz Común) 15 ArCERT c 2006

16 La interoperabilidad con otras aplicaciones semejantes son puntos importantes para no quedar atado a una aplicación. Va a ser necesario que maneje formatos y protocolos internos que sean estandares o de fácil migración a otros formatos. Una vez seleccionada la aplicación es recomendable seguirle los pasos de cerca en cuanto a sus nuevas versiones y bugs. Si la aplicación es un paquete Debian puede subscribirse a PTS 10. También es buena idea subscribirse a la lista de los desarrolladores si ésta fuera pública. 13. Firewall El servidor deberá estar operativo en una zona particular de la red, comúnmente llamada DMZ 11 cuando se trate de servicios externos, que será la única zona que recibirá conexiones desde afuera. Para restringir el acceso suele usarse un firewall. Pero además, cada host de nuestra red deberá tener un firewall propio, muchas veces llamado firewall de host. Como en todas las instalaciones de GNU/Linux, la herramienta utilizada para filtrar los paquetes de red en el host será iptables. Para facilitar la configuración, una opción es utilizar la herramienta shorewall, que si bien los ejemplos están pensados para un firewall en el sentido clásico (un gateway con filtrado de paquetes en modo stateful), es perfectamente adaptable al uso como firewall de host. También puede usarse fwbuilder, que es una herramienta gráfica para generar las reglas de iptables. Algunas recomendaciones a la hora de configurar el firewall: Permitir conexiones de entrada sólo a los puertos que tengan servicios publicos y que provengan de clientes en las redes que correspondan (por ejemplo, restringir el acceso desde otras máquinas de la DMZ, si el servicio es para Internet). Permitir la salida a Internet sólo a los sitios necesarios para la actualización del equipo y los servicios que así lo requieran, como conexiones al puerto smtp desde los servidores de correo electrónico. En algunos casos se puede poner un servidor de actualizaciones interno (con apt-proxy, por ejemplo), de manera que sólo éste requiera salida. Permitir la salida a otras máquinas de la DMZ sólo cuando sea para un servicio interno particular (por ejemplo, a una base de datos). 14. Actualizaciones de seguridad Ahora que ya tenemos el sistema medianamente asegurado, es el momento de actualizar los paquetes instalados. Editemos /etc/apt/sources.list que es el archivo que indica dónde encontrar dichas actualizaciones. Debe existir esta línea: deb sarge/updates main contrib non-free Una vez agregadas estas referencias, debemos actualizar la base de datos local de paquetes (como en la Figura 10) con el comando: debian: # apt-get update Y actualizar los paquetes, tal como se ve en la Figura 11 debian: # apt-get upgrade Posiblemente sea de utilidad que el administrador se subscriba a la lista de DSA 12, para estar al tanto de las actualizaciones en materia de seguridad. 10 Package Tracking System (Sistema de Seguimiento de Paquetes) 11 DeMilitarized zone (zona desmilitarizada) 12 Debian Security Announce (Anuncios de Seguridad en Debian) ArCERT c 2006

17 Figura 10: Actualización de la base de datos local para paquetes (apt-get update) Figura 11: Actualización de paquetes (apt-get upgrade) Con este último paso podemos considerar que hemos finalizado la instalación del sistema operativo, y estamos listos para comenzar a utilizarlo. El siguiente paso consistirá en configurar y asegurar los servicios que este equipo deba brindar (Web, Mail, etc.), pero eso lo dejamos para otros documentos. Luego de configurados los servicios, será el momento de realizar un back-up (véase Back-up) completo del sistema. 15. Mantenimiento El sistema que acabamos de instalar no está terminado, ya que evolucionará con el tiempo. Seguramente se le incorporará, quitará o modificará algún servicio o configuración. Por este motivo, habrá que tener en cuenta los conceptos de esta guía durante toda la vida del servidor. En particular, no debemos olvidarnos de realizar las actualizaciones de seguridad como se describe en la sección Actualizaciones de seguridad. Además habrá que hacer el seguimiento del servidor y tener una actitud proactiva con respecto a su seguridad. De ello hablaremos en esta sección Sincronización horaria En los próximos apartados insistiremos en la importancia de enviar a un host remoto y seguro los mensajes generados por el sistema. La única manera de correlacionar los eventos que observemos en diferentes equipos, será si sus relojes están perfectamente sincronizados. Por ello, es recomendable establecer un esquema de sincronización de relojes utilizando el protocolo NTP 13 Es muy normal contar con un servidor NTP en cada red, donde se sincronizan todas la máquinas y que, a su vez, está sincronizado con uno o más relojes externos. Las aplicaciones útiles para el esquema de sincronización pueden ser: ntpd, servidor NTP para Unix-like. OpenNTPD, puede ser una alternativa de configuración más sencilla. ntpdate, cliente NTP para Unix-like. Windows incluye un servicio para la sincronización horaria. 13 Network Time Protocol, protocolo de internet para sincronizar los relojes de los sistemas informáticos en redes con latencia variable ArCERT c 2006

18 15.2. Back-up Dentro de las tareas de mantenimiento, se encuentra la realización de back-ups periódicos del equipo. La discusión sobre los diferentes métodos existentes puede ser muy amplia. Sin embargo presentamos algunas recomendaciones para su ejecución: Para realizar back-up de muchos equipos de manera combinada, será necesario contar con un buen gestor de archivos de respaldo. Amanda 14 es una buena opción libre, compatible con muchos sistemas Unix-like (SCO, FreeBSD, IRIX, AIX, HP-UX, GNU/Linux), pero requiere Samba para trabajar con Windows. Otra herramienta muy usada, que sí tiene soporte para Windows, es bacula 15. La practicidad de las cintas nunca será superada por los medios ópticos (a menos que estos crezcan en capacidad más de lo que lo han hecho en los últimos años), o poseamos un intercambiador de CDs de gran capacidad. Es recomendable realizar backups full de manera periódica, e intercalarlos con back-ups parciales. Para que un back-up sea útil, es indispensable que pueda ser recuperado. Y para estar seguros de ésto, es necesario que la política de back-up incluya simulaciones periódicas donde restauremos nuestros sistemas desde las cintas. Considerar la posibilidad de guardar copias de los back-ups en sitios remotos, para contingencias mayores. Tener en cuenta que la sensibilidad de la información contenida en una cinta de back-up es igual a la información más sensible que haya sido almacenada, por lo que habrá que tomar los recaudos del caso. Los métodos más comunes de back-up en GNU/Linux son utilizar tar, cpio, o dump. Si no utilizamos un gestor de back-up, dump es una opción muy interesante por su manejo de niveles para copias incrementales y su integración con el sistema de archivos ext2/ext3. Como desventajas, tiene su lentitud, y que no es compatible con todos los filesystems existentes. La única forma de obtener una imagen exacta del disco, con la certeza de que no contendrá ningún tipo de inconsistencia, ni a nivel lógico del disco, ni a nivel transaccional de las aplicaciones, es realizar back-ups offline Auditorías regulares Una aplicación interesante para revisar la seguridad de nuestro servidor es tiger. Esta herramienta realiza diversas verificaciones sobre la configuración y el estado de varios elementos del sistema operativo. Permite realizar estos chequeos de manera períodica. La forma más recomendada para su instalación es junto con algunos paquetes auxiliares: debian: # apt-get install binutils chkrootkit lsof file libmagic1 tiger Con su instalación por defecto, tiger realizará diariamente las verificaciones y enviará un reporte de los problemas encontrados. Al igual que con las verificaciones de integridad (véase Chequeos de integridad ) y logs (véase Manejo de bitácoras (logs) ), será conveniente arbitrar los medios necesarios para que dicho reporte sea enviado a un equipo remoto con las medidas de seguridad del caso. La opción más común para este tipo de reportes es el envío por (a través de algún MTA local), pero también podrían utilizarse otros medios más seguros, como por ejemplo líneas seriales unidireccionales. En la Figura 12 se puede observar un reporte del análisis hecho por tiger ArCERT c 2006

19 Figura 12: Resultado del chequeo hecho por tiger (/var/log/tiger/security.report) Chequeos de integridad Cómo podemos descubrir si eventualmente el equipo resulta comprometido? Un excelente método es verificar la integridad de los archivos existentes en el sistema de archivos. Existen varias herramientas para realizar esta tarea: Tripwire, prácticamente la más antigua de todas (sólo de uso libre para Linux, y bajo ciertas condiciones de licenciamiento) Integrit, es un clon libre de tripwire. Debsums, que verifica la integridad de los archivos en base al hash contenido en el paquete Debian que lo provee. No todos los paquetes tienen los hashes necesarios, por lo que la herramienta no resulta práctica. AIDE 16, actualmente una de las más usadas y recomendables. En general estas herramientas proveen varias opciones de verificación, incluyendo hashes con uno o más algoritmos criptográficos, verificación de MAC time (Modificación, Acceso y Cambio), permisos, tamaño, etc. Todas proveen una configuración de ejemplo (en el caso de AIDE, /etc/aide/aide.conf) que servirá de punto de partida para una configuración adecuada al sistema que acabamos de instalar. Algunas de las cosas que habrá que modificar seguramente incluirán: Ni /etc, donde se encuentran todos los archivos de configuración, ni /boot, donde se encuentran los archivos de inicio del sistema operativo, están contemplados en el archivo de ejemplo. /var/log tiene algunas configuraciones específicas, que seguramente causarán varios falsos positivos si la actividad de nuestro host modifica los logs constantemente. /home sólo está contemplado como un ejemplo. Si el sistema posee muchos usuarios independientes, seguramente querremos verificar como mucho que no cambie el dueño (owner) de los archivos. Si no tiene usuarios además del administrador, vamos a querer observar cualquier tipo de cambio. Un buen método para ajustar la configuración es agregar todos los directorios dependientes del raíz faltantes (/boot, /home/, etc.) con todas las verificaciones posibles, e ir ajustándolas a medida que recibimos las alertas. Como mencionamos en caso de la auditoría interna, será conveniente que los reportes de estas verificaciones 16 Advanced Intrusion Detection Environment (Ambiente avanzado para la detección de intrusos) 19 ArCERT c 2006

20 sean recibidos en un host remoto, donde se tenga la seguridad de que podrán ser recuperados en caso de que una intrusión intente borrarlos. Además, para el caso de las verificaciones de integridad de los archivos, todos los métodos se basan en la creación de una base de datos con el estado inicial del sistema, y la posterior comparación con ésta. Si queremos que esta verificación sea efectiva, y no pueda ser falseada durante una intrusión, deberemos montar la base de datos en un dispositivo de sólo lectura. Por ejemplo, en un CD-ROM (o alguna clase de dispositivo al que se le pueda bloquear la escritura por hardware: un disquete, un pen-drive, una tarjeta flash, etc.) Manejo de bitácoras (logs) Los logs del sistema serán seguramente una de las herramientas más valiosas a la hora de atender un intento de intrusión al equipo, exitoso o no. En la mayoría de los sistemas UNIX-like, y por supuesto también en GNU/Linux, se utiliza el sistema syslog para manejar los logs del sistema. Este sistema consiste en un demonio que recibe los diferentes mensajes de las aplicaciones y el sistema operativo. Se configura a través del archivo /etc/syslog.conf, el cual tiene dos conceptos fundamentales: facility y level. El primero es la aplicación o el componente del sistemas operativo que genera logs. level hace referencia a la severidad del mensaje. Por cada combinación de estos se realiza una acción. El formato entonces quedaría: facility.level <Tab><Tab> acción Así, para cada tipo y severidad de log habrá un tratamiento, por ejemplo, escribir un mensaje en un archivo. Estos archivos, normalmente residen en el directorio /var/log. Como mencionamos en otros apartados, será conveniente que estos mensajes sean guardados en un repositorio externo, para evitar que sean falseados en caso de una intrusión. La forma más común de realizar esta tarea es enviarlos a otro host mediante el mismo protocolo syslog, de la siguiente manera: De esta manera, todos los mensajes (de cualquier tipo y nivel), serán reenviados al host loghost.ourdomain. Una alternativa mucho más segura, aunque pocas veces utilizada, es enviar los mensajes a través de un puerto serial a un loghost totalmente desconectado de la red. Existen alternativas 17 al sistema syslog, como syslog-ng 18, que permite mucha mayor flexibilidad en las acciones a tomar con los mensajes recibidos. Por último, mencionaremos una herramienta que puede ayudar a la lectura de los logs almacenados, que suelen tener un volumen importante. Esta herramienta es logcheck. La misma se basa en varias reglas, alojadas en el directorio /etc/logcheck, que definen por medio de expresiones regulares qué mensajes son importantes, y cuáles son inofensivos. Luego de seleccionar los mensajes según las reglas definidas, un resumen es enviado por . De la misma manera que en los casos anteriores, podría ser conveniente que este reporte sea enviado a un host remoto. Otra opción muy similiar es logwatch Herramientas para automatizar el fortalecimiento Existen algunas herramientas que pueden ayudarnos a asegurar un servidor. Dichas herramientas son útiles, pero por ninguna razón deben reemplazar el trabajo manual y el chequeo de las configuraciones por un administrador de sistemas Bastille Linux Esta herramienta, con bastante historia en GNU/Linux, consiste en una serie de preguntas que habrá que responder, para luego automatizar varias de las tareas que hemos realizado en este manual, y algunas otras que no syslog next generation ArCERT c 2006

21 Figura 13: Chequeo de los bits suid con bastille (InteractiveBastille) hemos cubierto. Se recomienda utilizar el mismo como una guía para ayudar a estas tareas, pero nunca para reemplazar la inspección personal de las mismas. Para instalar esta herramienta, al igual que con todos los paquetes, realizaremos la siguiente operación: debian: # apt-get install bastille Luego de finalizada la instalación, podemos ejecutar el modo interactivo mediante el siguiente comando: debian: # InteractiveBastille A continuación, se nos presentarán una serie de preguntas sobre las tareas a realizar, con una explicación de sus efectos posteriores. Por ejemplo, en la Figura 13 se observa a la aplicación consultando sobre la deshabilitación del bit suid en diversos programas Paquetes Harden Los paquetes harden de Debian son una serie de paquetes que, al igual que Bastille Linux, nos ayudarán a asegurar un sitio, pero no reemplazarán una buena configuración. Los paquetes harden se encargan de conflictuar con otros paquetes que, por alguna razón, son considerados inseguros. Por ejemplo, telnet que trabaja sobre protocolos sin cifrar. Entre otros, podemos encontrar harden-tools, que incluye algunas herramientas como el tiger, harden-doc, con documentación sobre seguridad, y harden-servers, harden-clients, harden-remoteflaws y harden-localflaws, que eliminan o limitan la instalación de paquetes con conocidos problemas de seguridad de distintos perfiles. 17. Otras fuentes de información Para obtener más información sobre seguridad en la distribución Debian: El manual completo de instalación de Debian puede obtenerse en: CheckList Pre-instalación 21 ArCERT c 2006