Gunnar Wolf
Departamento de Seguridad en Cómputo
FES Iztacala
CONSOL 2002
Este texto completo y actualizado estará disponible en la dirección http://www.gwolf.cx/seguridad/recom_seg_linux
El que diga saber todo acerca de Linux es una persona en la que no hay que confiar. Este es un trabajo no muy maduro. He de confesarlo --No muy maduro y hecho a las carreras. Si tienes cualquier corrección, modificación, agregado o lo que sea... Con mucho gusto, y por favor.
Primero que nada, en qué podemos confiar y en qué no cuando hablamos de Linux. Platicaremos un poco acerca del modelo de desarrollo --alabado y criticado-- conocido como el bazar, y a lo que este ha llevado. Un repaso acerca de las distribuciones, y de los mecanismos que tenemos a nuestro alcance para asegurar a nuestro sistema
Administradores y usuarios en general de sistemas Linux con ya cierta experiencia, con conocimiento de la operación y configuración básica, con inquietud acerca de la seguridad de sus sistemas
El material que te presento no te enseñará a profundidad ninguna de las acciones que comentaremos. Te presentará, sí, la forma básica en la que podrás hacerlo, pero Gunnar cree plenamente en la filosofía RTFM, y juzga imposible entrar en detalles acerca de cada detalle de la configuración. Gunnar cree plenamente que si te interesa un tema, no hay mejor recurso que el aprenderlo por tí mismo.
Claro, no puedo pretender que este tutorial lo incluya todo. Van de una vez varios recursos importantes. Me basé en varios de ellos para hacer este trabajo.
Por fín te convencieron. Linux es fácil. Linux es potente. Linux es grandioso. Linux es la diva bañada en yema de huevo. Te decides a instalarlo. Afortunadamente, a diferencia de los miles de chamaquitos que están dando una terrible fama de inseguro a este sistema operativo, a tí te importa la seguridad - Felicidades. Pero... ¿Qué vas a hacer al respecto? Tendrás que comenzar desde abajo.
Hay varias distribuciones de Linux, y entre sí pueden ser tan diferentes como dos Unixes sin relación entre sí. Afortunadamente, han mostrado una tendencia a converger sobre un número mucho menor de familias:
Si bien elegir una distribución es una labor que debe basarse en las necesidades, la experiencia y la opinión personal de cada uno de ustedes, se me haría muy difícil no dar mi punto de vista al respecto.
Mi recomendación personal, tanto para usuarios experimentados como para usuarios novatos, es definitivamente Debian. Para ambos habrá una curva de aprendizaje; para un novato, esta curva puede ser algo más empinada que para un experto, pero una vez conociendo la manera Debian de hacer las cosas, continuar con la administración del sistema es increíblemente más simple que en las basadas en RedHat.
Debian mantiene tres ramas simultáneas de versiones -- La estable, la de pruebas y la inestable, cada una de ellas con un nombre código. Actualmente (fines del 2001), las ramas son Potato (Stable), Woody (Testing) y Sid (Unstable). Al ser Debian una distribución mantenida por la comunidad y que busca el máximo de estabilidad y robustez, la rama estable es la indicada pra los servidores y demás máquinas críticas. Los paquetes que incluye no son los últimos disponibles, pero han sido ampliamente probados y no contienen ningún defecto importante que ponga en riesgo la estabilidad o entegridad del sistema. Potato fue congelado en agosto del 2000, y desde entonces sólo se le han añadido actualizaciones de seguridad.
La rama de pruebas --Woody-- está aún en desarollo, y se espera que sea congelada para convertirse en la próxima rama estable. Cuándo? No está aún determinado, pero probablemente hacia mediados del 2002. La respuesta que escucharán de cualquier desarrollador de Debian es cuando sea su tiempo. Woody puede ser ideal para escritorios o estaciones de trabajo. Dados los altos estándares de confiabilidad de Debian, yo no dudaría en recomendar a esta versión como tan estable como una versión definitiva de RedHat, y menos aún en la fase de desarrollo en que ahora estamos, en que poco a poco se va congelando Woody para reemplazar a Potato.
Por último, Sid es la rama para los usuarios que gustan estar al último grito en el desarrollo. Las últimas versiones los programas están siempre disponibles a sólo días de haber sido liberadas. Claro, el precio que hay que pagar a cambio es el saber que a veces algo puede tronar, lao puede desestabilizar al sistema entero o a algún subsistema.
Yo corro en mi escritorio con Sid, y muy rara vez he tenido que pelearme con él. Sin embargo, les sugiero fuertemente utilizar --al menos en un principio-- sólo Potato o Woody (o las ramas que en determinado momento sean stable o testing). Un paquete nuevo es admitido rápidamente en Sid, y una vez que ha demostrado no tener problemas importantes es enviado a Woody. Al finalizar el ciclo de congelación de Woody y éste sea nombrado estable nuestro paquete entrará en la rama estable. De otro modo, a menos que sea un parche importante de seguridad o funcionalidad, no entrará a estable.
Todo este rollo respecto a las ramas de Debian es para hacerte ver lo seriamente que toman en cuenta la estabilidad -- En Debian jamás habrá versiones estables oficiales tan defectuosas como la RedHat 7.0 o 7.1.
Un detalle más: Si lo que buscas es instalar un sistema operativo verdaderamente seguro, Linux no es el camino a seguir. Una distribución y una instalación de Linux pueden ser más o menos seguras, pero nunca serán realmente seguras. OpenBSD es lo que buscas. Un sistema operativo tipo Unix, libre (licencia BSD), diseñado con la seguridad y estabilidad como primer objetivo. Si quieres más información acerca de este sistema operativo, entra a la página oficial del proyecto OpenBSD [23] o a la página del grupo de usuarios de OpenBSD de México [24]. OpenBSD no es Linux, por lo que no lo seguiremos tratando en este tutorial.
Dicho lo cual, continuemos.
La instalación es lo primero para llevar a cabo el aseguramiento de una computadora. Si tenemos una computadora corriendo desde hace algún tiempo y no la hemos asegurado, probablemente sea más sencillo respaldar, formatear, reinstalar y asegurar antes de que pase nada a intentar asegurarla -- buscar una posible intrusión, una puerta trasera oculta en el sistema, alguna configuración modificada puede ser un trabajo demasiado complejo. Es práctica muy recomendable el no conectar la computadora a red recién terminada la instalación, sino que sólo hacerlo tras haberla asegurado.
Antes de instalar un sistema, el primer paso es analizar detalladamente para qué lo vamos a querer; qué servicios va a prestar, qué paquetes necesitamos para proveer dichos servicios, qué deseamos que pueda hacer. Empezar por el lado contrario (qué no quiero tener en el sistema) no lleva a ningún resultado real, aunque no niego es útil tener identificados los paquetes en los que no confiamos (¿ejemplos clásicos? wu-ftpd, imapd, fingerd, telnetd... Asómate a 2.2.2 para una mayor explicación) para no instalarlos ni por error, y hasta tener una reacción visceral al sólo verlos. Van un par de puntos relativos a la instalación de RedHat y de Debian.
Es muy diferente instalar una estación de trabajo e instalar un servidor. RedHat ofrece varias opciones predeterminadas de instalación rápida: Estación de trabajo GNOME, estación de trabajo KDE, servidor, o personalizada. Te sugiero fuertemente nunca elegir una opción predeterminada. Hacerlo equivale a solicitarle que instale todo lo que quien preparó la distribución cree que puede valer la pena -- tanto para servidor como para estación de trabajo, es altamente recomendable seleccionar instalación personalizada. De no hacerlo así, piensa por un momento -- ¿Qué lleva una instalación de servidor estándar? ¿Apache? ¿Samba? ¿Sendmail? ¿Bind? ¿dhcpd? ¿Postgres? ¿rntpd? ¿Squid? ¿POP3 e IMAP? ¿X? ... ¿Viene todo lo que necesitamos? ¿Necesitamos todo lo que viene? O tal vez más importante... Potencialmente, ¿puede hacernos daño algo que instalamos y no requerimos? Invariablemente: No, no, sí.
De hecho, si bien tomará mucho más tiempo, al instalar un servidor --una computadora que será visible a la red externa, que prestará servicios y probablemente sea blanco de ataques-- te recomiendo ampliamente seleccionar las categorías de paquetes que requieras, y después de eso indicar al instalador que quieres seleccionar paquete por paquete qué instalar. Vuelvo al ejemplo anterior -- Seleccioné instalar el servidor Apache, maravilloso... ¿Viene mod_perl? ¿PHP? ¿Apache_SSL? Los mismos inconvenientes del punto anterior, si bien mucho más locales. Al instalar un servidor es fundamental controlar la lista exacta de paquetes a ser instalada. No te preocupes demasiado por las dependencias, ya que si te falta algo el mismo programa instalador te dirá qué es cuando le pidas continuar. Si no sabes qué hace un paquete, oprime F1 y el instalador te dará su descripción. Como regla general, si dudas acerca de si un paquete te puede ser útil, puedes omitirlo. Si lo requieres, luego lo instalarás.
Estos mismos comentarios, claro está, se aplican a las instalaciones de estaciones de trabajo. Tal vez muchas veces descuidamos la seguridad de nuestra estación de trabajo... Pero es ahí donde hacemos todo el desarrollo y donde tenemos todos nuestros datos almacenados. No darle su muy buena pensada a los paquetes que instalaremos en nuestra estación de trabajo puede hacer peligrar doblemente nuestra seguridad.
La instalación básica de Debian es muy diferente para el nuevo usuario, pero tras un par de puntos verás que es prácticamente lo mismo. Lo primero que llama la atención al instalar Debian es la interfaz del instalador... ¿Estamos aún en 1995? ¿Y por qué la interfaz es de texto? Bueno... Antes de aventar en un ataque de ira los CDs de Debian, ponte a pensar... ¿Qué ventaja te da una instalación gráfica? Ninguna... Muy al contrario. Debian puede aún instalarse desde floppies en computadoras que no cuenten con unidad de CD (o si tienes una buena conexión a red y no quieres bajar el ISO completo), cosa que en RedHat es bastante más compleja, y el proceso es casi igual. Y --aclaro, esto es meramente opinión personal-- no existe una instalación más simple de efectuar que la de OpenBSD, cuya interfaz es un simple y llano script de shell. ¿para qué queremos pantallitas bonitas en un proceso que vamos a realizar una sóla vez? Mejor sencillez, simplicidad, funcionalidad.
Debian se instala en dos fases: Primero se instala el sistema base, fase durante la cual no hay mucho que acotar... Partición, módulos básicos, en fin, lo de siempre. Ya después de ello, con un sistema Unix funcional y tan completo como una instalación mínima lo permite, nos presenta los primeros detalles de configuración: Contraseña de root, cuenta de usuario, modo de manejo de las contraseñas. Entro más en detalle más adelante (2.3). Después de esto, al igual que en RedHat, nos da a escoger si queremos seleccionar los paquetes con la interfaz de experto (paquete por paquete) o simplificada (por categoría). Claro está, recomiendo fuertemente ir paquete por paquete. Recuerda que en este momento puedes elegir ya paquetes que tengas disponibles sobre la red... ¡Pero no bajes la guardia al instalarlos!
La interfaz que utilizas para seleccionar los paquetes es dselect -- Aprende a quererlo, que será probablemente uno de tus mayores aliados. Claro, hay varios programas más amigables que reemplazan a éste, pero comparten los principios básicos.
Al seleccionar paquetes, para instalar uno márcalo con +. Para eliminar un paquete, -. Si quieres eliminar también los archivos de configuración, _. Si quieres que no sea modificado el paquete cuando haya alguna actualización, =. Dselect (que no es más que una interfaz para apt-get) se encargará del manejo de dependencias.
El sistema ya está instalado, y arrancas tu computadora con una gran sonrisa en la boca. ¿¡Pero qué haces con...!? ¡Desconecta eso! ¡Sí, el cable de red! ¿Que por qué? Porque la máquina está demasiado abierta todavía. Analicemos:
Acabas de instalar el sistema operativo. No has cerrado ningún servicio que viene activo por default (ver 2.2.1). No has parchado aún posibles errores del sisetma (ver 2.4). No hay aún herramientas de seguridad instaladas (3.1, 3.3). A más de una persona le han logrado comprometer su sistema en los primeros minutos de vida, cuando más confiaba en él, y pocos se dan cuenta hasta semanas o meses más tarde. Hasta que tengas la computadora en un estado presentable, no conectes ese bonito cablecito. Y como veremos en 4.2 y 4.3, las amenazas son mucho más fuertes de lo que imaginamos.
Ahora, claro, probablemente se te ocurrió ya una falla fundamental en mi argumento: Varias distribuciones te permiten la instalación por red. Si, como yo, tienes una muy buena conexión a Internet, puedes juzgar innecesario bajar y quemar imágenes ISO para hacer instalaciones básicas, ¿cierto? Bueno... Lo importante es aislar a tu computadora de la red hostil tanto como sea posible. ¿Cómo? Hay muchas maneras... Probablemente puedas poner a tu computadora en una dirección IP no homologada (enmascarada), o puedas restringir con tu firewall que no reciba conexiones entrantes. El grado de conexión/no-conexión depende exclusivamente de tus necesidades y posibilidades.
Un concepto fundamental en seguridad es que no debes mantener abiertos servicios que no sean indispensables. Cualquier distribución viene, desafortunadamente, con varios puertos abiertos por default. Es muy raro que muchos de esos servicios sean utilizados hoy en día, y partiendo de que cualquier pedazo de código tiene altas probabilidades de tener un defecto interesante (y por tanto, explotable) escondido por ahí, entre más servicios estemos dando, más riesgo corremos de que nos peguen por aquella vulnerabilidad.
Hay varios protocolos que presentan un riesgo adicional: Por más seguro que sea un demonio, si requiere que la contraseña sea transmitida en texto claro (como lo hacen FTP, telnet, POP3, IMAP, etc.) abre nuestras máquinas a que un atacante olfatee la red esperando encontrar una contraseña, y la utilice para suplantar la identidad de su dueño. Estos servicios, claro está, deben ser también cerrados, o por lo menos, entubados en una conexión cifrada, como lo veremos en 3.2.2.
Una herramienta invaluable para asistirte al controlar acceso a los servicios que proporcionamos en nuestro sistema es un firewall, ya sea como un sistema dedicado o como reglas locales de filtrado, como lo veremos en 4.4.
Vayamos primero sobre del superdemonio, inetd. Este superdemonio está encargado de levantar una potencialmente gran cantidad de programas servidor para varios servicios, típicamente de baja complejidad pues funciona mejor con programas que no cueste mucho tiempo inicializar. Bajo el riesgo de equivocarme en alguno, en inetd vienen abiertos varios servicios, como chargen, echo, telnet, ftp, rsh, rexec, rwho, talk, finger, ident.
Además de ser innecesarios hoy en día, pueden ser muy peligrosos. ¿Ejemplos? Con identd, finger, rwho y chargen es posible averiguar información acerca de quién está usando y qué está corriendo una comptuadora --información, claro, muy valiosa para un atacante. Varios de estos demoniostambién han presentado casos de buffer overflows.
Muy bien, ya eché mi rollote... Ahora bien, ¿Cómo puedo cerrar servicios innecesarios? Fácil: El archivo de configuración de inetd es el /etc/inetd.conf, y su sintaxis es muy sencilla. A mí me toca todavía más fácil: No tengo que enseñarte cómo agregar servicios a inetd (que para eso está la página del manual, claro ;-) ), sino que simplemente cómo cerrarlo.
Este archivo se puede analizar línea por línea. Primero que nada, ¿qué es un comentario? Cualquier cosa después de un signo #. Si el signo # está al principio de la línea, toda la línea es considerada un comentario y su significado es nulo para inetd.
Todas las líneas que no son comentarios y no están en blanco inician con ya sea una palabra o un número. Éste es el que define qué servicio ejecutará -- por ejemplo, la línea:
telnet stream tcp nowait telnetd.telnetd /usr/sbin/tcpd /usr/sbin/in.telnetdindica que estamos hablando de telnet. Claro, la computadora tendrá que traducir esto a un número de puerto; para esto extá el archivo /etc/services, donde nos indica que telnet corresponde al puerto 23 de TCP. Si queremos deshabilitar ese servicio, únicamente tenemos que comentar la línea en cuestión, de esta manera:
#telnet stream tcp nowait telnetd.telnetd /usr/sbin/tcpd /usr/sbin/in.telnetdDespués de hacer los cambios pertinentes, reiniciamos inetd. Esto puede ser -dependiendo del tipo de Linux que tengamos- de una de las siguientes maneras:
/etc/init.d/inetd stop; /etc/init.d/inetd start para Debian
/etc/rc.d/init.d/inetd stop;/etc/rc.d/init.d/inetd start para RedHat y derivados anteriores al 7.0
Cabe mencionar que la versión 7.0 y superiores de RedHat (y es de esperarse que otras varias distribuciones sigan este ejemplo) incluye a un reemplazo para inetd llamado xinetd. La configuración general, localizada en el archivo /etc/xinetd.conf es:
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
Con xinetd tenemos un control más granular acerca del comportamiento de cada uno de los servicios. Por ejemplo, en la configuración anterior vemos que xinetd limitará a 60 instancias (conexiones simultáneas), lo cual puede reducir dramáticamente los ataques de negación de servicio. En este ejemplo vemos también cómo las conexiones serán registradas en las bitácoras del sistema. Y en vez de definir cada servicio en una línea, en el directorio /etc/xinetd.d tenemos un archivo por servicio (toman el nombre de las líneas definidas en /etc/services) como el siguiente, /etc/xinetd.d/telnet:
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = yes
}
La mayoría de los campos son análogos a los que vemos en inetd.conf -- La única diferencia clara es el campo enable. En vez de comentar la línea, basta con marcar disable=yes para que el servicio no sea iniciado.
Cuál de los dos usar? Es completamente cuestión de preferencia personal. xinetd te da la ventaja de mayor granularidad, inetd presenta un panorama más claro de qué está activo y qué no. Mi recomendación, personal y subjetiva, va por inetd, ya que siendo hoy cada vez menos (y menos importantes) los servicios proporcionados a traves de este mecanismo, se me hace más importante tenerlos centralizados en un solo archivo que el poner controles específicos a cada uno de ellos -- Labor muy fácil de hacer, de todos modos, ya sea a través de TCPWrappers o de reglas de filtrado de paquetes.
Por otro lado, tenemos los demonios per sé, los programas que están contínuamente corriendo en nuestro sistema. En un sistema Linux típico basado en SysVR4 (no Slackware), encontraremos qué programas demonio tenemos corriendo examinando los directorios de inicio. Para esto, consultamos en qué runlevel estamos ejecutando (busca la línea id:x:initdefault: en tu archivo /etc/inittab; el número que esté en la x será el runlevel en el que entra tu sistema por default. Este será típicamente 2 para Debian, y 3 o 5 para RedHat.
Con esto en mente, hay dos sopas: Hacerlo a mano o a través de un programita que nos ayude. Si tienes RedHat y quieres irte por el camino fácil, ejecuta /usr/sbin/ntsysv.
Si sigues leyendo esto, eres de los míos: Quieres saber cómo funcionan las cosas. Te felicito de antemano. Vamos a entrar en materia. A propósito, si utilizas Debian y quieres hacer esto a su más puro estilo, tienes a update-rc.d, que de todos modos asume que sabes manejar tu sistema.
Dentro de /etc (o de /etc/rc.d, si estás usando un sistema RedHat 6.2 o anterior) encontrarás los directorios init.d, rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d y rc6.d. Algunos sistemas tendrán también a rcS.d. En init.d están los scripts de arranque/finalización de todos tus demonios, y en los demás directorios (uno por cada runlevel) hay ligas simbólicas hacia dichos scripts, con una convención especial en el nombre: {K|S}##xxxx, donde:
gwolf@mipc:/etc$ ls rc2.d/ S10sysklogd S20dhcp S20inetd S20lpd S20snort S89cron S99wdm S12kerneld S20exim S20ipac S20makedev S20ssh S91apache S14ppp S20gpm S20logoutd S20postgresql S89atd S99rmnologin
Esto significa que al encender el sistema o entrar a runlevel 2, éste inicia (en órden) la ejecución de sysklogd, kerneld, ppp, dhcp, exim, gpm, inetd, ipac, logoutd, lpd, makedev, postgresql, snort, ssh, atd, cron, apache y rmnologin.
Para evitar que un demonio inicie en el runlevel default basta con quitar la liga hacia él; por ejemplo, si decides que ya no requieres dar servicios de Apache, basta con la siguiente línea:
rm -f /etc/rc2.d/S91apache
O bien, si usas Debian, puedes hacer:
update-rc.d -f apache remove
El crear la liga con la K nos sirve para indicar que al entrar a este runlevel, en caso de que cierto demonio esté corriendo, lo mate. Recuerda que podemos cambiar de runlevels sin reiniciar el sistema, con el comando
init x
Siendo x el runlevel al que queremos entrar.
Hay algunos servicios que funcionan sobre un mecanismo llamado Remote Procedure Call (RPC). Algunos de estos son NFS, NIS/YP, y otros. La mayor parte de los usuarios hoy en día no requieren a ninguno de ellos, y creen que basta con detener al demonio indicado. Portmap es, sin embargo, un demonio que guarda información acerca de todos estos demonios; mucha gente ignora la existencia de Portmap, sin embargo, y lo deja corriendo.
Una gran cantidad de exploits han aparecido aprovechando debilidades en el diseño de Portmap. Te sugiero fuertemente que lo desactives y elimines del sistema a menos que realmente lo requieras. Muchos sistemas lo levantan desde rcS.d, otros varios desde cada runlevel en específico.
Portmap es iniciado como demonio independiente, y escucha por el puerto 111.
Mención especial entre los servicios nefastos merecen los llamados r-commands - Comandos remotos. Estos servicios aparecieron cuando Internet era todavía una red académica y confiable; están hechos para permitir hacer ciertas operaciones fácilmente entre computadoras. Los principales r-commands son:
Todos estos comandos pueden, además, ser reemplazados con sus equivalentes seguros con Secure Shell, con la misma sintaxis y prácticamente el mismo nombre (ver 3.2.1
Nuestra principal preocupación en este momento son típicamente los ataques provenientes de la red1. netstat es un comando que podemos encontrar en todo Unix, y que nos permitirá cerciorarnos de que no estamos dando más servicios de los estrictamente requeridos. Esta, claro, es sólo una de las funciones que tiene netstat - siendo una herramienta tan útil, te sugiero leer su página de manual si no estás familiarizado con él.
En este caso, voy directo sobre una de las formas de invocar a netstat. Nos interesa saber qué puertos tiene abiertos nuestro sistema. Vamos primero sobre los puertos TCP:
mipc:~# netstat -nap |grep -w 'LISTEN\|udp' tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 828/inetd tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 227/X tcp 0 0 0.0.0.0:1024 0.0.0.0:* LISTEN 219/wdm tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 209/apache tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 194/sshd tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN 169/lpd udp 0 0 0.0.0.0:177 0.0.0.0:* 219/wdm udp 0 0 0.0.0.0:67 0.0.0.0:* 150/dhcpd-2.2.x
Los modificadores nap (p está disponible únicamente en Linux, n y a son estándares en otros Unixes) y los filtros aplicados nos indican:
Históricamente, RedHat se ha empecinado en incluir paquetes que han demostrado ser altamente vulnerables a ataques, probablemente por no haber tomado en cuenta la seguridad en su etapa de diseño... Y los siguen incluyendo hoy en día.
Coincidentemente (o tal vez no), estos paquetes provienen en su mayoría de la Universidad de Washington. Para todos ellos, te sugiero desactivarlos y desinstalarlos. Si requieres la funcionalidad que ofrecen, inetnta instalar un programa substituto, casi todos tendrán uno disponible.
Hoy en día, casi todas las distribuciones presentan la posibilidad de utilizar shadow passwords y MD5. ¿Qué es esto?
Tradicionalmente, en los sistemas Unix manejamos todas las cuentas del sistema en el archivo /etc/passwd, donde tenemos los datos generales del usuario así como su contraseña cifrada con el algoritmo DES del NIST. Este es un algoritmo de cifrado de 64 bits, excelente en su momento, pero casi trivial de tronar con el poder de cómputo actual -- ¡Y el archivo de contraseñas requiere ser legible para todos los usuarios del sistema! Esto se solventa con dos mecanismos.
Conforme pasa el tiempo, nuevos errores de programación se van encontrando en prácticamente todos los programas. Muchas veces, estos errores se ven reflejados en vulnerabilidades que pueden comprometer nuestro sistema completo. Es por tanto indispensable que nos mantengamos al día con los parches.
Actualizar un sistema RedHat es muy sencillo. Claro, el primer paso para actualizar es estar informado. La mejor fuente para hacerlo será una lista de correo específica de tu distribución; de todos modos; de todos modos, la lista de anuncios de RedHat [28] es siempre un buen punto de referencia.
Claro está, durante la instalación y al dar los primeros pasos -insisto- la computadora no está conectada. Te sugiero hacer un CD con las actualizaciones que hayan salido hasta el momento -entre 50 y 200MB normalmente- e instalar todo lo que requieras con el comando
rpm -Fvh /mnt/cdrom/*
Claro, con el directorio en donde tengas los RPMs en vez de /mnt/cdrom si es el caso. La opción F de RPM es para que actualice únicamente los paquetes que requiere actualizar. Por ejemplo, si en mi computadora no instalé bind, instalar la actualización de bind sería inútil o hasta contraproducente (pues puede introducir vulnerabilidades que no existían previamente en el sistema); con F no se instalaría, aunque sí se instalaría cualquier otro paquete requerido.
Debian nos presenta una gran ventaja respecto a cualquier otra distribución: El sistema apt-get. Conviene tener la siguiente línea en el archivo /etc/apt/sources.list, que indica a apt-get dónde buscar los programas a instalar:
deb http://security.debian.org stable/updates main contrib non-free
Actualizar el sistema completo puede ser hecho simplemente con los comandos:
apt-get update; apt-get dist-upgrade
apt-get tiene una gran cantidad de opciones; si bien correr esto a diario te ayudará a mantener el sisetma al día, hay varias salvedades para las cuales es imprescindible leer la documentación.
Como nota al pie, apt-get es un sistema tan poderoso que nos permite actualizar el sistema completo a una versión más nueva de la distribución con tan sólo indicarlo, sin romper dependencias ni crear conflictos. apt-get es gran parte de la razón por la que los miles de usuarios de esta distribución la aprecian tanto por sobre de RedHat y otras distribuciones.
Prácticamente todas las distribuciones incluyen ya algunas de las herramientas de seguridad que en su momento parecieron tremendamente innovadoras y hoy en día son ya dadas por hecho, como es el caso de los maravillosos TCP-Wrappers de Wietse Venema. sin embargo, hay varias herramientas que pueden serte muy útiles. Instalarlas es lo de menos... Y de ahí en más, verlas correr, verlas analizar tu sistema, verlas velar por tí es sencillamente un deleite. Algunas de ellas son:
No sé cómo estas dos herramientas no vienen instaladas por default en todo sistema Unix. Ambas son parte del proyecto Abacus de Psionic [29].
Portsentry es un detector de barridos de puertos e intentos de conexión a puertos cerrados, que no sólo previene sino que toma acción correctiva bloqueando toda comunicación entre el posible atacante y nuestro sistema. Prácticamente todos los ataques comienzan con una fase de recopilación de información, en que el atacante intenta encontrar todos los datos posibles acerca de nuestro sistema... Y Portsentry lo manda a volar sin darle oportunidad de aprender prácticamente nada respecto a nosotros. Para un tutorial más a fondo de Portsentry, consulta [].
Revisar las bitácoras es una de las obligaciones más importantes, pero más tediosas y menos queridas, de un administrador de sistemas. Esto es en buena parte porque tenemos que acordarnos de hacerlo, tenemos que recordar en qué línea nos quedamos, no hay manera automática de prioritizar los mensajes, y nos toca analizar bloques bastante grandes (te gustan unas 600 líneas diarias en un sistema con actividad moderada?). Logcheck te simplifica esta tarea, enviándote a tu buzón con el intervalo que le especifiques (te sugiero una hora), acomodado por prioridades, lo que llegue a tu bitácora. Si quieres más al respecto, asómate a []
Las redes hoy en día son --y afortunadamente lo sabemos-- inseguras, y nos imposibilitan confiar en lo que transportan. El cifrado a todos niveles nos permite asegurar por lo menos los siguientes puntos, fundamentales para virtualmente toda operación:
Una gran ventaja de los sistemas Unix es su capacidad de ser administrados remotamente. Por muchos años, telnet fue una maravillosa herramienta para hacer esto. Adicionalmente, FTP nos permitía la transferencia de archivos entre sistemas, y el sistema de ventanas X desde un principio permitió el manejo transparante de conexiones remotas. Sin embargo, como ya saben, eso ya no es suficiente gracias a la facilidad y frecuencia de los olfateos en una red.
Secure Shell nos permite hacer todo esto, de una manera segura y cifrada. Pensado originalmente como reemplazo de telnet/rlogin/rsh/rexec (para manejar sesiones remotas), hoy incluye a scp y sftp, para la copia de archivos remotos, y dentro del mismo ssh, el mecanismo para crear túneles de puertos sobre canales cifrados, lo que nos permite, entre otras muchas cosas, utilizar sesiones X remotamente sin preocuparnos por intrusos espiando nuestra conexión -- y sabiéndolo utilizar, ssh nos puede dar toda la infraestructura necesaria para una VPN completa.
No hay excusa hoy en día para no tener Secure Shell instalado en nuestros sistemas, al igual que no hay excusa para utilizar conexiones no cifradas.
Algunas aplicaciones hoy en dia, pese a lo que recién comenté, no pueden ser manejadas por Secure Shell. Un ejemplo muy clásico es el de las máquinas Windows cliente que consultan su correo en nuestro servidor -- y hay muchos más. Si bien no podemos exigir a nuestros usuarios que utilicen Secure Shell para crear canales cifrados antes de abrir una sesión de correo (imagínalo simplemente...), sí podemos poner a su disposición versiones cifradas con el estándar SSL de los protocolos inseguros que manejan. La mayor parte de los clientes de correo reconocen los puertos 993 y 995 para IMAP y POP3 (respectivamente) sobre SSL. Stunnel nos permite cifrar cualquier protocolo, siempre que el programa cliente comprenda también SSL.
Probablemente el programa de cifrado más conocido en el mundo sea PGP. Desde su polémica aparición hace 10 años ha permitido a todo mundo tener acceso a criptografía fuerte junto con un robusto esquema de redes de confianza para llaves públicas, lo que en español significa que nos permite mantener nuestras comunicaciones cifradas y seguras.
GnuPG, la versión GNU de PGP, esta ya perfectamente al nivel de su predecesor, garantizándonos todas las libertades que nos da trabajar con software GNU, siendo compatible con el PGP original.
Dirán lo que quieran, pero las herramientas clásicas de seguridad siguen siendo una importantísima herramienta para asegurar y verificar nuestro sistema. Puedes encontrarlas en el FTP del Departamento de Seguridad en Cómputo - ftp://ftp.seguridad.unam.mx, y muchas veces dentro de tu misma distribución de Linux.
Una instalación default de Linux incluye ya a algunas de estas herramientas completamente integradas al sistema, notablemente a passwd+, shadow y TCP Wrappers.
Estudiar las principales herramientas de seguridad está más allá del propósito de este texto. Asómate a los tutoriales del Departamento de Seguridad en Cómputo [32]. En general, las herramientas de seguridad pueden clasificarse en:
Bastille Linux [33] es un conjunto de scripts diseñados para ayudar a cerrar los posibles problemas en las distribuciones derivadas de RedHat, y recientemente han aparecido paquetes de Bastille en la rama de desarrollo de Debian. Un punto muy positivo de Bastille es que cada paso que da lo explica al operador, evitando crear agujeros en su conocimiento - tanto o más importantes que los del sisetma.
Bastille Linux es un proyecto muy ambicioso y vital; casi a diario aparecen noticias en su página, y es de esperarse que en un futuro cercano o medio sea integrado a más de una distribución de Linux.
El proyecto OpenWall [34] creó un grupo de parches disponibles para el kernel del Linux, y una muy buena forma de prevenir ataques como Buffer Overflows y similares. Son una coleccion de mejoras de seguridad para integrar en bloque en el kernel, configurables todas ellas desde una nueva sección de Seguridad que es añadida al menu de configuración del kernel, y que verás a la hora de reconfigurarlo. Estos parches estan disponibles para diferentes versiones del kernel, pero hay que recalcar que no son parte de la distribución central. algunos de sus puntos son:
Bueno... Tu sistema está ya cuidadosamente instalado, parchado, asegurado y listo para el mundo. Hora de dejar que tu esfuerzo rinda frutos -- Estás ya listo para conectarlo a Internet.
Claro está, el esfuerzo no termina aquí. Día a día aparecen nuevas amenazas, día a día tenemos que protegernos y estar mejor preparados que nuestro contrincante. Es imposible resumir todo lo que esto implica, pero menciono algunos puntos importantes.
Hay varios lugares con información acerca de nuevos problemas de seguridad, incluyendo vulnerabilidades. Lo primero que debes hacer, como lo mencioné en 2.4.1, es subscribirte a la lista de anuncios de tu distribución; ahí siempre tendrás la última información tan pronto sea liberada. Otra lista muy importante es Bugtraq [35], de SecurityFocus, donde se discuten posibles vulnerabilidades, y sirve muchas veces como base para la reacción de las diferentes distribuciones.
Hay varios sitios importantes que merecen visitas periódicas. ¿Cada cuánto? Entre más seguido, mucho mejor. De nuevo, son demasiados. Los primeros que recuerdo son:
Los gusanos no son un nuevo concepto; el primer incidente documentado sobre Internet fue, justamente, el famoso gusano de Morris, en 1989. Sin embargo, la moda actual de los gusanos data de hace relativamente poco tiempo - En enero del 2001 apareció el gusano Ramen y poco después tuvimos a Lion. Ambos explotaban fallos de seguridad en las distribuciones de RedHat 6.2 y 7.0. En julio, agosto y septiembre del 2001 tuvimos la proliferación de gusanos atacando a las diferentes versiones de Windows NT: Code Red, Code Blue, Code Green, Code Rainbow, Nimda... Siguiendo, todos ellos, el mismo patrón. Lo que es peor, explotando las mismas vulnerabilidades de sistemas mal configurados.
Estos gusanos atacan indiscriminadamente, buscando de manera automática un host al que atacar buscando dirección por dirección en enormes segmentos de red, y conectándose únicamente al puerto al que saben explotar. Hay a la fecha gusanos que explotan FTP (21/tcp), DNS (53/udp), Portmap (111/tcp), LPR (515/tcp) y HTTP (80/tcp). La cura? Simple: Tener el sistema al día. Los gusanos no son inteligentes, saben atacar únicamente a una versión de un demonio. Si actualizas la versión vulnerable por una más nueva, quedarás a salvo de sus ataques.
Un punto importante: Ten mucho cuidado de parchar todas las máquinas de tu segmento, no sólo los servidores principales. Aún si no te duele que una máquina sea atacada pues no hace nada importante, ésta comenzará a atacar a todas las computadoras que pueda, chupando todo el ancho de banda del que dispongas y posiblemente metiéndote en problemas de responsabilidad legal, pues el comportamiento de tus computadoras es responsabilidad tuyo.
Es muy común encontrar que nuestro sistema está siendo barrido (¿Instalaste portsentry, verdad?). Las primeras veces siempre te alarman, hasta que te des cuenta que es algo normal. Sin embargo, cada que recibas un barrido... Revisa una vez más que no haya nada raro en tu sistema, y toma nota de la dirección orígen. Si recibes barridos con frecuencia de la misma dirección, revisa quién es el responsable de dicha red, y repórtale el incidente, de la manera más detallada posible, incluyendo horas de inicio y término de los barridos registrados.
Para averiguar los datos de contacto del responsable de una red, utiliza el servicio whois de ARIN (http://www.arin.net/whois/index.html, dominios del continente americano), InterNIC (http://www.internic.net/whois.html, dominios genéricos), RIPE (http://www.apnic.net/, dominios europeos) o APNIC (http://www.apnic.net/, dominios de Asia y el Pacífico), estos engloban a la gran mayoría de las direcciones asignadas.
Prácticamente toda computadora Unix es capaz de manejar reglas de firewall. Esto es muy útil aún cuando esta no sea el firewall central de la organización -- El tener reglas de filtrado de paquetes para determinar a quién se le proporciona cada uno de los servicios añade un muy gran nivel de control a nuestro equipo.
Linux maneja para el filtrado de paquetes diferentes sistemas, dependiendo de la versión de kernel. Con la versión 2.0.x o anteriores, el sistema manejado era ipfwadm; con la versión 2.2.x se cambió a ipchains, y en la versión 2.4.x se maneja iptables. Toda nueva versión (hasta ahora) soporta la sintaxis de la versión anterior, si bien agrega capacidades suficientemente interesantes para hacer que valga la pena aprender a manejar la propia.
La sintaxis de las reglas de firewall, desafortunadamente, no es tan simple como en la manejada por IPF, disponible para los demás Unixes, o PF, disponible en OpenBSD. Sin embargo, la sintaxis básica es muy simple.
Trabajaremos aquí únicamente con ipchains, si bien la sintaxis de iptables es bastante similar, y sólo con un nivel que nos permitirá crear las reglas más básicas que requiera nuestra computadora. Para un firewall en forma, te remito al tutorial que preparó uno de sus principales autores, Rusty Russell [36]. La información que yo presento aquí viene exclusivamente de la página de manual de ipchains [37].
Cuando el código de firewall del kernel está activo, hay tres cadenas principales por las que pasa un paquete: INPUT, OUTPUT y FORWARD. Además de esto, podemos crear cadenas definidas por el usuario.
Para definir a política que seguiremos con los paquetes que nos interesen, definimos reglas sobre cada una de las cadenas. Cada una de estas reglas especifica el criterio para que un paquete sea tratado de diferente manera, e indican cómo será tratado el paquete. Estas reglas pueden tener uno de los siguientes objetivos:
Y por último, los parámetros: Definimos cuándo se aplica cada una de las reglas cuando se cumple. Podemos negar uno de estos criterios con !:
Por ejemplo, el siguiente comando agrega una regla que bloquea todos los paquetes provenientes de la red 192.168.0.0/24 al puerto de Web (80):
ipchains -A INPUT -p tcp -s 192.168.0.0/24 -destination-port 80 REJECTY el siguiente permite que llegue a este puerto únicamente la computadora 192.168.0.25:
ipchains -A input -p tcp -s 192.168.0.25 -destination-port 80 ACCEPTCrear reglas es, por qué no aceptarlo, bonito y divertido... Pero llega mucho más allá de lo que persigo con este tutorial.
Un sistema de detección de intrusos (IDS) es muchas veces visto como parte de un firewall. Hay quien cree que por estar enviando a la bitácora notificación de los paquetes rebotados ya tiene un sistema de IDS. Gran mentira. Un IDS es justamente la herramienta que detectará comportamiento hostil dentro de una conexión legítima - Por ejemplo, mi firewall va a permitir que cualquiera hable con el puerto 80 (http) de mi servidor de Web. Sin embargo, ¿qué pasa si recibo la siguiente solicitud?
GET ../../../../etc/passwd
¡Esto enviaría mi archivo de contraseñas a quien lo solicitara! (claro está, ningún servidor de web hoy en día accedería a un ataque tan primitivo) Y este ataque, sea o no exitoso, debe ser detectado a tiempo y, de ser posible, detenido.
Hay dos tipos de IDSs: Los que están dedicados a monitorear actividad sospechosa en el host mismo (IDSs orientados a host) y los que monitorean la red buscando huellas de intentos de ataque, no necesariamente hacia la computadora en que están alojados (IDSs orientados a red).
Hay una gran cantidad de programas que cumplen estas funciones: TripWire [38] detectará modificaciones a los archivos que le especifiquemos, HostSentry (parte del proyecto Abacus, [29]) nos reportará anomalías relativas al uso de cuentas de usuario en nuestros sistemas.
Hay muchos otros IDSs orientados a host, y de hecho, muchos programas que en realidad no fueron explícitamente diseñados como uno pueden ser clasificados como tales.
La importancia de los IDSs orientados a host es mucho mayor de lo que mucha gente piensa: Hay una infinidad de maneras de conseguir acceso elevado en casi cualquier sistema, y una vez que el atacante lo tiene, cualquier cosa que haga parecerá --ante un IDS orientado a red-- actividad normal y legítima.
Hay un claro primer lugar en IDSs orientados a red libres: Snort [39]. Este detector de intrusos cuenta con una gran cantidad de firmas para identificar los diferentes ataques, es relativamente sencillo de mantener, y se mantiene bastante al día. Ahora, Snort por sí solo lo único que hará es registrar los intentos de ataque. Para que este IDS realmente nos sea útil, requerimos herramientas que procesen de alguna manera útil los datos que reciben de Snort. Algunas de ellas son:
Tras quién sabe cuánto tiempo y esfuerzo dedicados a leerme o escucharme hablar --esfuerzo muy loable-- te tengo una maravillosa noticia: Ya acabamos. Si tienes alguna duda que no haya resuelto, si quieres más detalle en algún punto, ahora es cuándo para solicitarlo.
Quedo a tus órdenes. Mi dirección de correo es gwolf@campus.iztacala.unam.mx, y te repito, el texto completo de este tutorial lo tendrás disponible y (hasta donde pueda mantenerlo) actualizado en http://www.gwolf.cx/seguridad/recom_seg_linux
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.48)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir14290zhzMdf/lyx_tmpbuf0/recom_seg_linux.tex
The translation was initiated by Gunnar Wolf on 2003-10-15