Security Sp2

•

IP: Firewalling (CONFIG_IP_FIREWALL) Esta opcion es necesaria si va a configurar su maquina para actuar como cortafuegos, va a usar IP Masquerading, o desea proteger su maquina conectada via modem contra intrusiones a traves de su interfaz de red PPP.

•

IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) Esta opcion le permite obtener informacion acerca de los paquetes que recibe su maquina cortafuegos, como origen, destino, puerto, etc.

•

IP: Drop source routed frames (CONFIG_IP_NOSR) Esta opcion deberia ser habilitada siempre. Los “Source routed frames” son paquetes que contienen la ruta completa a seguir para alcanzar su destino. Esto significa que los routers a traves de los cuales pasan estos paquetes no necesitan inspeccionarlos, y simplemente les dejan seguir su camino. Esto puede conducir a que su sistema sea explotado.

•

IP: masquerading (CONFIG_IP_MASQUERADE) Si una de las maquinas de su red local (para las que su maquina Linux actua como cortafuegos) quiere enviar algo al exterior, la maquina Linux puede “enmascararla”, es decir, hacer de intermediario transparente entre la maquina cliente de su red local y la maquina del exterior, de forma que para la maquina del exterior es la maquina Linux la unica visible. Para mas informacion: http://www.indyramp.com/masq

•

IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) Esta opcion complementa a la anterior, proporcionando soporte para “enmascarar” paquetes ICMP. Si no la habilita, solo podra “enmascarar” paquetes TCP y UDP.

•

IP: transparent proxy support (CONFIG_IP_TRANSPARENT_PROXY) Esta opcion permite que su cortafuegos Linux redirija de forma transparente cualquier trafico con origen en la red local y con destino a una maquina remota a un servidor local, llamado “servidor proxy transparente” de forma que las maquinas de la red local piensan que estan accediendo a una maquina remota cuando en realidad lo estan haciendo al servidor proxy local. Vea el IP-Masquerading HOWTO si desea mas informacion. http://www.indyramp.com/masq

•

IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG)

Normalmente esta opcion esta deshabilitada, pero si esta preparando una maquina para hacer de cortafuegos o servir IP-Masquerading, querra habilitarla. Cuando circula informacion entre dos maquinas, no siempre lo hace en un unico paquete, si no que los paquetes son normalmente divididos en porciones mas pequeñas (fragmentos). El problema es que la direccion del puerto de destino solo figura en el primer fragmento. Esto significa que alguien puede insertar informacion en los fragmentos restantes que no deberia estar ahi. Esta opcion tambien protege contra el “teardrop attack” a las maquinas Linux que aun no esten “parcheadas”. •

Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING) Esta opcion esta disponible en los kernel mas modernos ( >=2.1.x ) y marca los paquetes NCP para una mayor seguridad. Normalmente no hara falta habilitarla, pero esta ahi por si se necesita.

•

IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK) Esta opcion le permite analizar los primeros 128 bytes de los paquetes desde un programa de usuario, para determinar si se desea aceptarlos o rechazarlos en funcion de su validez.

7.2. Opciones de compilado para kernels 2.2.x La mayoria de las opciones enumeradas anteriormente son aplicables a los kernels 2.2.x, ademas de algunas nuevas que han sido desarrolladas despues. Muchos de los comentarios proceden del archivo Configure.help, que se encuentra en /usr/src/linux/Documentation. Todos los mensajes de ayuda que es posible visualizar durante la etapa “make config” de la configuracion del kernel proceden tambien de este archivo. A continuacion se mencionan solo las nuevas opciones. El cambio mas significativo en los kernels de la serie 2.2.x se ha producido en el codigo que gestiona el cortafuegos IP. Ahora se utiliza una utilidad llamada ipchains para administrarlo, en lugar del programa ipfwadm, que era el que se usaba con los kernels 2.0.x.

•

Socket Filtering (CONFIG_FILTER) Para la mayoria de la gente, es correcto decir que no a esta opcion. Sirve para “conectar” un filtro mediante el uso de un programa de usuario a cualquier “socket” y determinar si un paquete debe ser aceptado o rechazado. A menos de que tenga una necesidad muy especifica y sea capaz de programar usted mismo dicho filtro, deberia decir que no. Tenga en cuenta tambien que en el momento de redactar este documento, todos los protocolos estan soportados excepto el TCP.

•

Port Forwarding: el “port forwarding” es un complemento al IP Masquerading que permite redirigir paquetes del exterior a maquinas protegidas tras el cortafuegos a puertos especificados. Esto puede ser util si, por ejemplo, quiere ejecutar un servidor de paginas “web” en una maquina protegida por el cortafuegos Linux y desea que dicho servidor pueda accederse desde el mundo exterior. Un cliente del

exterior manda una peticion al puerto 80 de la maquina cortafuegos, el cortafuegos redirige esta peticion a la maquina que corre el servidor “web”, y el servidor procesa la peticion y envia la pagina solicitada al cliente original a traves del cortafuegos. Cara al cliente, es la propia maquina cortafuegos la que parece estar ejecutando el servidor “web”. Tambien puede utilizarse para repartir la carga entre varios servidores “web” identicos protegidos tras el cortafuegos. Puede obtener informacion sobre esta caracteristica en las URL’s: http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html ftp://ftp.compsoc.net/users/steve/ipportfw/linux21/ •

Socket Filtering (CONFIG_FILTER): Si habilita esta opcion, un programa de usuario puede habilitar un filtro en cualquier “socket” y de esta forma decir al kernel si debe o no permitir que determinado tipo de datos pasen a traves de el. El filtrado de “sockets” de Linux funciona con todos excepto con los del tipo TCP por ahora. Vea el archivo de texto /usr/src/linux/Documentation/networking/filter.txt para mas informacion.

•

IP Masquerading: el IP-Masquerading en los kernels 2.2.x ha sido mejorado. Ahora tiene soporte adicional para protocolos especiales, etc. Asegurese de leer el IPChains HOWTO para mas informacion.

7.3. Dispositivos del Kernel Hay algunos dispositivos de bloque y de caracter disponibles en Linux que tambien le ayudaran a aumentar la seguridad. Los dos dispositivos /dev/random y /dev/urandom se suministran con el kernel a fin de proporcionar datos aleatorios en cualquier momento. Tanto /dev/random como /dev/urandom deberian ser lo suficientemente seguros para usarse en la generacion de llaves PGP, desafios SSH, y en otras aplicaciones donde se requieran numeros aleatorios seguros. Los atacantes deberian ser incapaces de predecir el siguiente numero aleatorio que sera generado por estos dispositivos aun disponiendo de una secuencia inicial de ellos. Se ha puesto mucho esfuerzo en asegurarse de que los numeros que se obtienen de estos dispositivos son aleatorios en todos los sentidos de la palabra. La unica diferencia entre ellos es que /dev/random puede quedarse sin bytes aleatorios y hacerle esperar hasta que se acumulen algunos nuevos. Tengase en cuenta que en algunos sistemas esto puede hacer que la maquina detenga su actividad durante mucho tiempo a la espera de que el usuario produzca actividad que pueda ser usada para generar nuevos numeros aleatorios. Por eso debe ser cuidadoso al utilizar /dev/random. (Tal vez la mejor forma de hacerlo sea usarlo solo cuando necesite generar informacion sensible, como contraseñas, etc, haciendo que el usuario tenga que teclear continuamente hasta recibir un mensaje del tipo “ok, ya es suficiente...”) /dev/random posee una entropia de alta calidad, generada a partir de la medicion del tiempo entre interrupciones, etc, pero se bloquea hasta que se acumulan suficientes bits de datos aleatorios.

/dev/urandom es similar, pero cuando el montante de entropia baja, devuelve una cadena que es producto de encriptar fuertemente los datos aleatorios de los que se dispone todavia. Esto no es tan seguro como el metodo usado por /dev/random, pero es suficiente para la mayoria de las aplicaciones. Se puede leer de estos dispositivos con una orden como: root# head -c 6 /dev/urandom | mmencode Esto mostrara en la consola seis caracteres aleatorios, susceptibles de ser utilizados en la generacion de una contraseña. Puede encontrarse el programa mmencode en el paquete “metamail”. Si desea ver una descripcion del algoritmo, puede encontrarla en el archivo /usr/src/linux/drivers/char/random.c Gracias a Theodore Y. Ts’o, Jon Lewis, y a otra gente del Linux-kernel por ayudarme (Dave) con esto.

8.

Seguridad de Red

La seguridad de red se esta volviendo mas y mas importante a medida que la gente pasa cada vez mas tiempo conectada. Los ataques contra la seguridad de red son casi siempre mas faciles de realizar que aquellos contra la seguridad fisica o local, y son mucho mas frecuentes. Existen buenas herramientas para ayudar a mejorar la seguridad de red, y un numero de ellas cada vez mayor esta siendo incluido en las distribuciones de Linux.

8.1. “Packet Sniffers” Una de las formas mas comunes mediante la que los intrusos ganan acceso a mas sistemas en su red es empleando un “sniffer” de paquetes en una maquina que ya haya sido comprometida. El “sniffer” simplemente “escucha” a traves del dispositivo ethernet a la espera de capturar paquetes que contengan cadenas como “login” o “passwd”. De esta forma, un intruso puede conseguir acceso a sistemas en los que ni siquiera intentaba introducirse. Las contraseñas sin encriptar son muy vulnerables a este tipo de ataque. Ejemplo: la maquina A ha sido comprometida. El atacante instala un “sniffer”. El “sniffer” detecta el acceso remoto de un administrador accediendo a la maquina B desde la maquina C. Despues, ese administrador hace un “su” para arreglar un problema. El atacante ya tiene la contraseña de “root” de la maquina B. Mas tarde el administrador permite que alguien conecte mediante telnet a su cuenta en una maquina remota que llamaremos Z. El atacante tambien obtiene un login/password valido en la maquina Z. En los tiempos que corren, el atacante ni siquiera necesita comprometer una primera maquina para instalar el “sniffer”: podria introducirse en un edificio con un ordenador portatil y conectarlo directamente a uno de los “hub” de la red que desea atacar. El uso de SSH o cualquier otro metodo que haga circular las contraseñas encriptadas puede evitar este tipo de ataques. Tambien es interesante el uso de APOP para

cuentas POP de correo (los accesos POP normales son muy vulnerables a esto, como todas las comunicaciones que envien a traves de la red contraseñas sin encriptar).

8.2. Servicios de Sistema y los “tcp_wrappers” Antes de conectar su sistema Linux a NINGUNA red lo primero que debe ver es que servicios necesita ofrecer. Los servicios innecesarios deberian deshabilitarse de forma que tenga usted una cosa menos de la que preocuparse, y los atacantes un lugar menos donde buscar un agujero. Existen varias formas de deshabilitar servicios en Linux. Se puede mirar en el archivo /etc/inetd.conf y ver que servicios estan siendo ofrecidos por inetd. Desactive lo que no necesite poniendo un “#” delante de la linea correspondiente, y enviando luego un SIGHUP al proceso inetd. N. del T: para enviar señales a un proceso, primero debe averiguar el numero asignado a dicho proceso (“man ps”) y despues enviarle la señal deseada (“man kill”). El comando “kill” no solo sirve para acabar con un proceso, como parece sugerir su nombre. Tambien se pueden quitar (o comentar con “#”) servicios en el archivo /etc/services. Esto significara tambien que los clientes locales no podran encontrar el servicio (por ejemplo, si elimina el ftp e intenta hacer ftp a una maquina remota, el comando fallara dando un mensaje de error “unknown service”). Normalmente no merece la pena hacer esto, ya que no proporciona seguridad adicional. Se puede decir al programa de ftp que utilice el puerto FTP habitual, y funcionara aunque el servicio no figure en /etc/services. Algunos de los servicios que puede que desee dejar activos son: • • • •

ftp telnet (o ssh) correo, como pop-3 o imap identd

Si sabe que no va a utilizar un determinado paquete (ftpd, httpd, etc) puede eliminarlo totalmente de su sistema. El metodo para hacerlo dependera en gran medida de la distribucion que utilice. Sin duda se deben deshabilitar las utilidades rsh/rlogin/rcp, incluyendo login (usado por rlogin), shell (usado por rcp), y exec (usado por rsh) eliminando o comentando (#) las lineas adecuadas en /etc/inetd.conf. Estos protocolos son EXTREMADAMENTE INSEGUROS y han sido ampliamente explotados en el pasado. Deberia comprobar el archivo /etc/rc.d/rcN.d (donde N es el “run-level” en el que corre normalmente su sistema) y ver si alguno de los servicios iniciados desde ese directorio no es necesario. Los archivos que residen en /etc/rc.d/rcN.d son en realidad vinculos simbolicos al directorio /etc/rc.d/init.d. Renombrar los archivos en el directorio init.d tiene como efecto el deshabilitar los vinculos simbolicos en /etc/rc.d/rcN.d. Si desea deshabilitar un servicio unicamente para un “run-level” en particular, renombre el archivo apropiado cambiando la “S” mayuscula por una “s” minuscula, tal que: root# cd /etc/rc6.d

root# mv S45dhcpd s45dhcpd Si sus archivos rc son del estilo BSD, debera comprobar /etc/rc* en lugar de los mencionados anteriormente (que son estilo System V) ya que es desde estos archivos desde donde se lanzan los servicios. La mayoria de las distribuciones de Linux incluyen “tcp_wrappers”. Un “tcp_wrapper” (tcpd) es invocado por inetd en lugar del servidor real. El tcpd comprueba que maquina solicita el servicio y ejecuta el programa servidor del servicio especificado, o bien deniega el acceso si la maquina solicitante no esta autorizada. El tcpd le permite restringir el acceso a sus servicios TCP. Para ello deberia crear un archivo /etc/hosts.allow y poner en el a aquellos sistemas que deban tener acceso a los servicios de su maquina. Si es usted un usuario que se conecta desde casa via modem, le sugerimos que deniege el acceso a sus servicios a todo el mundo. El tcpd ademas mantiene un registro (log) de todos los intentos fallidos de acceder a los servicios, proporcionando una forma de averiguar que se esta siendo objeto de un ataque. Si añade nuevos servicios a su maquina, deberia asegurarse de que utilizan “tcp_wrappers” si estan basados en TCP. Por ejemplo, un usuario normal que se conecte via modem puede prevenir que un intruso se conecte a su maquina, y seguir siendo capaz de recoger el correo de una cuenta remota, o realizar cualquier otro tipo de conexion a Internet. Para esto, podria poner lo suiguiente en /etc/host.allow: ALL: 127. y, por supuesto, /etc/hosts.deny contendria: ALL: ALL con lo cual evitara que se realicen conexiones desde el exterior a su maquina, mientras sigue siendo posible conectarse a servidores remotos en Internet. Recuerde que el uso de los “tcp_wrappers” solo protege a los servicios que son ejecutados por inetd, y unos pocos mas. Es muy probable que su maquina ofrezca otros servicios. Puede usar la orden “netstat -ta” para obtener una lista de todos los servicios que ofrece su maquina.

8.3. Verifique su Informacion DNS Mantener actualizada la informacion DNS de todas las maquinas de su red puede ayudarle a incrementar la seguridad. Si una maquina no autorizada llegase a conectarse a su red, podria reconocerla por su falta de una entrada en el servidor DNS. Muchos servicios pueden ser configurados para no aceptar conexiones procedentes de maquinas que no tengan una entrada DNS valida.

8.4. identd Identd es un pequeño programa que habitualmente es ejecutado por el servidor inetd. Sirve para mantener un registro de que usuario esta usando que servicio TCP, y facilitar esta informacion a cualquiera que lo solicite.

Mucha gente entiende mal la utilidad de identd, y por ello lo deshabilitan o bloquean las peticiones dirigidas a el. Identd no esta ahi para ayudar a las maquinas remotas. No existe ninguna forma de saber si la informacion que se obtiene de un identd remoto es correcta o no. No se realiza ningun tipo de autentificacion en las peticiones a identd. ¿Por que querria usted ejecutar identd entonces? porque le ayuda, y es una fuente mas de informacion util. Si su identd no ha sido comprometido, entonces sabe que esta informando a maquinas remotas del nombre de los usuarios locales que esten usando servicios TCP. Si el administrador de una maquina remota le dice que uno de sus usuarios esta intentando entrar ilegalmente en su sistema, puede usted facilmente tomar medidas contra este usuario. Si no ejecuta identd tendra que examinar un inmenso volumen de archivos de registro y perder un monton de tiempo para dar con el usuario en cuestion. El identd que viene con la mayoria de las distribuciones es mas configurable de lo que mucha gente cree. Se puede deshabilitar para usuarios especificos (mediante el uso de un archivo .noident), se puede mantener un registro de todas las peticiones identd recibidas por su maquina (esto es lo que se recomienda),puede hacer incluso que identd devuelva un UID numerico en lugar del nombre del usuario, etc.

8.5. SATAN, ISS, y Otros Scanners de Red Hay varios paquetes de software circulando por ahi que sirven para escanear las maquinas de una red y determinar que puertos ofrecen algun servicio. SATAN, ISS, SAINT y Nessus son algunos de los mas conocidos. Estos programas se conectan a la maquina objetivo (o a todas las maquinas de una red) a todos los puertos que pueden, e intentan determinar que servicio esta ejecutandose en cada puerto. A partir de esta informacion se puede deducir si una maquina podria ser vulnerable a algun “exploit” contenido en los ejecutables que proporcionan dichos servicios. SATAN (Herramienta de Seguridad del Administrador para Analizar Redes) es un escaneador de puertos con un interfaz “web”. Puede configurarse para que realice chequeos “ligeros”, “medios” o “fuertes” a una maquina o a una red. No es mala idea conseguir el programa SATAN y escanear su propia maquina o red, para corregir despues los problemas que se encuentren. Asegurese de conseguir su copia de SATAN o bien de metalab http://metalab.unc.edu/pub/packages/security/Satan-for-Linux/ o bien de algun otro sitio fiable. Habia una copia “caballo de troya” de SATAN circulando por Internet. http://www.trouble.org/~zen/satan/satan.html Tengase en cuenta que SATAN no ha sido actualizado desde hace tiempo, y algunas de las herramientas mencionadas a continuacion podrian hacer mejor el trabajo. ISS (Escaner de Seguridad en Internet) es otro escaneador de puertos. Es mas rapido que SATAN, y por lo tanto podria ser mejor para redes grandes. En cualquier caso, SATAN suele proporcionar mas informacion. Abacus es un conjunto de herramientas que proporcionan seguridad basada en la maquina (“host-based”) y deteccion de intrusos. Si desea mas informacion, puede visitar su pagina “web” en la direccion: http://www.psionic.com/abacus/

SAINT es una version actualizada de SATAN. Tambien posee un interfaz “web” y tiene muchos “tests” mas actualizados que los de SATAN. Puede averiguar mas sobre esta herramienta en la direccion: http://www.wwdsi.com/~saint Nessus es un escaner de seguridad libre. Tiene un interfaz grafico GTK para facilitar su utilizacion. Tambien esta diseñado con una interesante funcion de adicion de nuevos “tests” (“plugins”). Para mas informacion, eche un vistazo en la direccion: http://www.nessus.org

8.5.1.Detectando un Escaneo de Puertos Existen algunas herramientas diseñadas para alertarle si su sistema es objeto de un escaneo por parte de SATAN, ISS y otros programas de funcion similar. En cualquier caso, usando adecuadamente los “tcp_wrappers” y asegurandose de echar un ojo a sus archivos “log” regularmente, deberia ser capaz de detectar dichas actividades sin necesidad de software adicional. Incluso con el modo mas “suave” de funcionamiento, SATAN todavia deja rastro en los archivos de registro de un sistema RedHat convencional. Existen tambien escaneadores de puertos “sigilosos”. Un paquete con el bit TCP ACK activado (como los que se usan para establecer conexiones) podria pasar a traves de un cortafuegos por filtrado de paquetes. El paquete RST devuelto desde un puerto que “_had no established session_” (???) puede considerarse una prueba de que existe actividad en ese puerto. No creo que los “TCP wrappers” detecten esto.

8.6. sendmail , qmail y los MTA’s Uno de los mas importantes servicios que puede usted proporcionar es un servidor de correo. Desafortunadamente, es tambien uno de los mas vulnerables a los ataques, sencillamente a causa del numero de tareas que debe realizar y de los privilegios que normalmente necesita. Si utiliza usted sendmail es muy importante mantenerse siempre actualizado a las ultimas versiones. Sendmail tiene una MUY larga historia de agujeros de seguridad. Asegurese siempre de que esta utilizando la version mas reciente, que puede obtener en la direccion: http://www.sendmail.org Recuerde que para enviar correo no es necesario que ejecute sendmail. Si es usted un usuario domestico, puede deshabilitar sendmail y utilizar sencillamente el programa cliente de correo para enviarlo. Puede que tambien desee eliminar el modificador “-bd” del archivo de inicializacion de sendmail, lo que desabilita el que se atiendan peticiones de correo procedentes del exterior. En otras palabras, se puede ejecutar sendmail desde uno de los “scripts” de inicializacion usando: # /usr/lib/sendmail -q15m

Esto hara que sendmail vacie la cola de correo cada quince minutos en busca de mensajes que no hayan podido ser enviados con exito en el primer intento. Muchos administradores prefieren no usar sendmail, y en su lugar eligen alguno de los demas agentes de transporte de correo (MTA’s). Puede que le resultase interesante cambiarse a qmail. Qmail fue diseñado con la seguridad en mente desde el principio. Es rapido, estable y seguro. Puede encontrar el programa qmail en la direccion: http://www.qmail.org En competicion directa con qmail esta “postfix”, escrito por Wietse Venema, el autor de varios “tcp_wrappers” y de otras herramientas de seguridad. Antiguamente llamado vmailer, y patrocinado por IBM, este agente de transporte de correo tambien esta diseñado pensando en la seguridad desde un principio. Puede encontrar mas informacion sobre vmailer en la direccion: http://www.postfix.org

8.7. Ataques de Denegacion de Servicio Un ataque de denegacion de servicio (“denial of service”, “DoS”) es aquel en el que el atacante intenta hacer que un determinado recurso este tan ocupado que no pueda atender peticiones de usuario legitimas, incluso impidiendo a los usuarios legitimos el acceso a la maquina. Los ataques de denegacion de servicio se han incrementado enormemente en los ultimos años. Algunos de los mas populares y recientes se listan a continuacion. Tenga en cuenta que continuamente aparecen nuevas formas de realizar un ataque de este tipo, por lo que la lista siguiente no es mas que un ejemplo. Lea las listas de correo sobre seguridad en Linux y demas documentacion relacionada para mantenerse al corriente de la aparicion de nuevos tipos de ataque. •

“SYN Flooding” - Este es un ataque de denegacion de servicio de red. Se aprovecha de un “bucle-agujero” en la forma en que se crean las conexiones TCP. Los kernels de Linux mas modernos (2.0.30 y siguientes) poseen varias opciones de configuracion para prevenir este tipo de ataques. Vea la seccion “Seguridad del Kernel” para conocer estas opciones de proteccion.

•

El “bug F00F” del Pentium - Ha sido descubierto recientemente que el envio de una determinada secuencia de instrucciones en codigo maquina a un procesador Intel Pentium genuino hace que la maquina se reinicie. Este problema afecta a todos los ordenadores que tengan un procesador Intel Pentium (no a los Cyrix, AMD, Pentium Pro ni Pentium II) independientemente del sistema operativo que ejecuten. Los kernels de Linux a partir del 2.0.32 contienen una porcion de codigo que evita este problema. Si posee un procesador Pentium, deberia actualizar su kernel a una de estas versiones inmediatamente.

•

“Ping Flooding” - Este es un simple ataque por fuerza bruta. El atacante “bombardea” la maquina victima con un flujo continuado de paquetes ICMP. Si la maquina atacante posee un ancho de banda mayor, la maquina victima no podra enviar nada a la red. Una variante de este ataque, llamada “smurfing”, envia los

paquetes ICMP con la direccion IP de retorno modificada, haciendo mas dificil determinar el origen real del ataque. Puede encontrar mas informacion sobre el ataque “smurf” en la direccion: http://www.quadrunner.com/~chuegen/smurf.txt Si alguna vez sufre un ataque “ping flood”, utilice una herramienta como tcpdump para determinar de donde vienen los paquetes (o de donde parecen venir), y suministre esa informacion a su proveedor. Estos ataques pueden ser facilmente prevenidos a nivel del “router” o bien mediante el uso de un cortafuegos. (N. del T: El comando “ping” suministrado en la mayoria de las distribuciones de Linux admite el parametro “-f” para generar un flujo masivo de paquetes ICMP. Por supuesto, esta opcion solo puede ser utilizada por el superusuario.) •

El “Ping de la Muerte” - Este ataque envia paquetes ICMP ECHO REQUEST (ping) que son demasiado grandes para caber en las estructuras de datos del kernel donde se almacenan. Como la recepcion de un unico paquete “ping” de 65510 bytes hace que muchos sistemas se bloqueen, este problema recibio rapidamente el sobrenombre de “ping de la muerte”. Hace tiempo que este problema ha sido corregido, de manera que no hay que preocuparse por el.

•

“Teardrop”/”New Tear” - Una de las formas de ataque mas recientes se aprovecha de un “bug” en el codigo que maneja la fragmentacion IP en plataformas Windows y Linux. Ha sido corregido en la version 2.0.33 del kernel, y no es necesario seleccionar ninguna opcion de compilado para utilizar esta mejora. Aparentemente Linux es inmune al ataque “New Tear”. Puede encontrar el codigo de la mayoria de los “exploits” y una descripcion mas profunda de como trabajan usando el motor de busqueda disponible en la direccion: http://www.rootshell.com

8.8. Seguridad NFS (Network File System). El NFS es un protocolo de uso compartido de archivos ampliamente utilizado. Permite que un servidor que ejecute nfsd y mountd “exporte” sistemas de archivos a otras maquinas que tengan soporte cliente NFS en el kernel (o algun otro tipo de software cliente si no se trata de maquinas Linux). Mountd mantiene un registro de los sistemas de archivos montados en /etc/mtab, que puede ser visualizado mediante el uso del comando showmount. Muchos sistemas usan NFS para servir los directorios “home” de los usuarios, de manera que independientemente de la maquina de la red mediante la que accedan siempre tienen acceso a sus archivos personales. Hay pocas opciones de seguridad a la hora de exportar archivos con NFS. Si esta obligado a usar NFS, asegurese de exportar permitiendo acceso solo a las maquinas que realmente lo necesiten. Nunca exporte el directorio raiz de un sistema. Exporte solo los directorios que se necesiten.

Para mas informacion, vea el NFS-HOWTO disponible en la direccion: http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html

8.9. NIS (Network Information Service) (antiguamente YP). El Servicio De Informacion de Red es un metodo para distribuir informacion a un grupo de maquinas. El servidor NIS maestro contiene las tablas de informacion y las convierte en archivos NIS mapeados. Estos “mapas” son despues servidos a la red, permitiendo que las maquinas cliente obtengan toda la informacion contenida en un archivo /etc/passwd estandar (login, password, directorio “home”, “shell” para el usuario, etc). Esto permite, por ejemplo, que un usuario cambie su contraseña solo una vez y que este cambio tenga efecto en todas las maquinas del dominio NIS. El NIS no es para nada seguro, ni nunca pretendio serlo. Fue diseñado para ser util y manejable. Cualquiera que pueda averiguar el nombre de un dominio NIS (en cualquier sitio de la red) puede conseguir una copia del archivo passwd y utilizar “crack” o “John the Ripper” para obtener contraseñas validas. Tambien es posible “spoofear” al servidor NIS y realizar toda clase de trucos perversos. Si esta obligado a usar NIS, asegurese de que conoce los peligros que implica. Existe un sustituto para NIS mucho mas seguro, llamado NIS+. Para mas informacion, lea el NIS-HOWTO, disponible en: http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html

8.10. Cortafuegos (firewalls) Un cortafuegos es una forma de controlar que informacion puede salir o entrar en una red. Tipicamente, la maquina cortafuegos esta conectada a Internet y tambien a la red local, de forma que el unico camino posible para los paquetes de la red local con destino a Internet sea a traves de la maquina cortafuegos. De esta forma, el cortafuegos puede controlar todo el trafico que fluye de la red local a Internet y viceversa. Hay varios tipos de cortafuegos y metodos para configurarlos. Las maquinas Linux constituyen un cortafuegos bastante bueno. El codigo de cortafuegos se puede compilar en los kernels 2.0 y superiores. Las herramientas de usuario (ipfwadm para kernels 2.0.x, ipchains para 2.2.x) permiten cambiar “en caliente” los tipos de trafico de red permitidos. Tambien permiten mantener un registro de un determinado tipo de trafico de red. Los cortafuegos constituyen una util e importante tecnica para proteger su red. No obstante, nunca piense que por el hecho de tener un cortafuegos no necesita proteger las maquinas que se encuentran tras de el. Este es un error fatal. Para mas informacion sobre Linux y los cortafuegos, le remitimos al magnifico documento Firewall-HOWTO, disponible en: http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html Tambien encontrara informacion interesante en el IP-Masquerade mini-howto: http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html

Si desea ampliar su conocimiento de ipfwadm (la herramienta de usuario para gestionar el cortafuegos de los kernels 2.0.x) visite: http://www.xos.nl/linux/ipfwadm/ Si no tiene ninguna experiencia con cortafuegos, y planea configurar uno para algo mas que una politica de seguridad sencilla, el libro “Firewalls” de O’Reilly y Asociados, asi como alguna otra documentacion sobre cortafuegos serian de obligada lectura. Visite para mas informacion: http://www.ora.com El Instituto Nacional de Estandars y Tecnologia posee tambien un excelente documento sobre cortafuegos. Aunque data de 1995, todavia sigue vigente. Puede encontrarlo en la direccion siguiente: http://csrc.nist.gov/nistpubs/800-10/main.html Otras fuentes interesantes de informacion relacionada con los cortafuegos son las siguientes: •

El Proyecto Freefire - contiene una lista de herramientas de cortafuegos de libre distribucion, y la direccion es: http://sites.inka.de/sites/lina/freefire-l/index_en.html

•

Diseño de Cortafuegos SunWorld - escrito por los autores del libro de O’Reilly mencionado anteriormente, proporciona una introduccion a los diferentes tipos de cortafuegos. Puede encontrarlo en: http://www.sunworld.com/swol-01-1996/swol-01-firewall.html

8.11. IP Chains - Cortafuegos de los kernel de Linux 2.2.x El “Linux IP Firewalling Chains” es una actualizacion del codigo de cortafuegos de los kernels 2.0.x para los de la serie 2.2.x. Proporciona muchas mas opciones que las implementaciones anteriores, incluyendo: • • • • • •

Una manipulacion mas flexible de los paquetes. Una contabilidad (registro) mas compleja. Posibilita realizar facilmente cambios simples en la politica. Los fragmentos de paquetes pueden ser explicitamente bloqueados, etc. Es posible generar un registro (log) de los paquetes “sospechosos”. Puede manejar otros protocolos ademas de ICMP/TCP/UDP.

Si usted usa actualmente ipfwadm con su kernel 2.0.x, existen “scripts” a su disposicion que le permiten cambiar el formato de las ordenes de ipfwadm al utilizado por ipchains. Asegurese de leer el IP-Chains HOWTO si desea mas informacion. Puede encontrarlo en la direccion: http://www.rustcorp.com/linux/ipchains/HOWTO.html

8.12. VPN’s - “Virtual Private Networks” o Redes Privadas Virtuales. Las VPN’s son una forma de crear una red “virtual” sobre otra red ya existente. Esta red virtual a menudo usa algun sistema de encriptado y unicamente permite el trafico entre algunas maquinas bien conocidas que se unen a esta red virtual. Las VPN’s se utilizan habitualmente para conectar la maquina de alguien que trabaja desde casa con la red interna de su empresa usando una red virtual encriptada que corre sobre otra red publica, normalmente Internet. Si esta usando un cortafuegos Linux con “masquerading” y necesita dejar pasar paquetes MS PPTP (un producto VPN punto a punto de Micro$oft), existe un parche para el kernel de Linux que permite justamente esto. Vease: ip-masq-vpn. Existen varias soluciones VPN para Linux disponibles: •

vpnd. Visite: http://www.crosswinds.net/nuremberg/~anstein/unix/vpnd.html.

•

Free S/Wan, disponible en: http://www.xs4all.nl/~freeswan/

•

Puede utilizarse SSH para construir una VPN. Vea el VPN mini-HOWTO para mas informacion.

•

vps (virtual private server) disponible en: http://www.strongcrypto.com.

Vease tambien la seccion sobre IPSEC para obtener mas direcciones donde obtener mas informacion sobre este tema.

9. Preparacion de la Seguridad (antes de conectar la maquina a la red). Bien, ya ha chequeado su sistema y ha determinado que es lo mas seguro posible. Ahora ya esta listo para conectarlo a la red. Hay algunas cosas que deberia hacer ahora con el fin de estar preparado contra una posible intrusion, de manera que pueda rapidamente deshacerse del intruso, y volver a dejar el sistema listo para seguir trabajando normalmente.

9.1. Haga una Copia de Seguridad Completa de su Maquina La discusion de los metodos de copia de seguridad y almacenaje de las mismas va mas alla del alcance de este documento, pero ahi van algunas palabras acerca de las copias de seguridad: Si tiene menos de 650MB de datos en cada particion, una copia a CD-ROM es bastante interesante (ya que una copia de seguridad en CD es dificil de manipular, y si se guarda de forma adecuada puede durar mucho tiempo). Las cintas magneticas y otros soportes re-grabables deben protegerse contra escritura nada mas finalizar el proceso de copia de seguridad, y deben verificarse despues para asegurarse que no han sido modificados. Asegurese de almacenar las copias de seguridad en un lugar seguro. Una buena copia de seguridad le proporciona un buen punto de partida desde el que restaurar un sistema totalmente destruido. (N. del T: Cierta vez escuche una historia acerca de como una empresa quedo totalmente desvalida al sufrir un incendio que acabo tanto con sus ordenadores como con sus copias de seguridad, realizadas regularmente de forma impecable pero que se almacenaban en el mismo edificio que los ordenadores. La moraleja es que se deben guardar las copias de seguridad en un lugar diferente a donde residen fisicamente las maquinas).

9.2. Planificando una buena politica de copias de seguridad Un ciclo de seis cintas es facil de mantener. Esto incluye cuatro cintas para los dias de la semana de lunes a jueves, una cinta para los viernes pares y otra para los viernes impares. Realice una copia incremental los dias ordinarios, y una copia de seguridad completa todos los viernes a la cinta que corresponda. Si en algun momento realiza cambios particularmente importantes en el sistema, una copia completa no estara de mas.

9.3. Haga una copia de la base de datos RPM o Debian En el caso de sufrir una intrusion, puede utilizar la base de datos RPM de archivos instalados en el sistema tal y como utilizaria tripwire, pero solo si sabe a ciencia cierta que dicha base de datos no ha sido modificada por el intruso. Deberia copiar la base de datos RPM a un disquete, y mantener este disquete a buen recaudo. La distribucion Debian utiliza un sistema similar a la base de datos RPM. Los archivos /var/lib/rpm/fileindex.rpm y /var/lib/rpm/packages.rpm (la base de datos RPM) posiblemente no caben en un disquete, pero una vez comprimidos deberian caber cada uno de ellos en un disquete. Asi, si su sistema se ve comprometido, puede usar el comando: root# rpm -Va para verificar cada archivo del sistema. Vea la pagina de manual del comando rpm, ya que hay algunas otras opciones que pueden incluirse para hacer que el comando proporcione menos informacion (???). Tenga en cuenta que debe estar seguro de que el binario RPM no ha sido comprometido.

Esto significa que cada vez que instale un nuevo paquete RPM en el sistema debera volver a hacer una copia de seguridad de la base de datos RPM. Tendra que evaluar usted mismo las ventajas y los inconvenientes de este sistema.

9.4. Este pendiente de la informacion de registro del sistema Es muy importante que la informacion procedente del syslog no sea comprometida. Hacer que los archivos del directorio /var/log tengan permisos de escritura y lectura solo para un numero de usuarios limitado es un buen comienzo. Asegurese de saber que es lo que se va a escribir en esos archivos, especialmente por el servicio auth. Varios intentos fallidos de hacer “login” por parte de un usuario, por ejemplo, pueden indicar un intento de penetracion en el sistema. El lugar donde debe buscar los archivos de registro del sistema depende de la distribucion de Linux que utilice. En un sistema que cumpla el “estandar de sistema de archivos de Linux”, como RedHat, los encontrara en /var/log con los nombres messages, mail.log, etc. Puede averiguar donde pone su distribucion los mensajes del syslog examinando el archivo /etc/syslog.conf, ya que este archivo es el que determina donde deben escribirse los distintos mensajes del sistema. Puede que desee tambien configurar un sistema que ponga a salvo los archivos de registro hasta que disponga de tiempo para examinarlos. La distribucion RedHat incluye un paquete llamado “logrotate” que sirve para esto. Es muy posible que otras distribuciones incluyan paquetes de funcionalidad similar. Si sus archivos de registro han sido manipulados, vea si puede determinar a partir de donde estan manipulados, y que tipo de cosas parecen haber sido modificadas o borradas. ¿Hay grandes periodos de tiempo durante los cuales no se realizo ningun registro? mirar en las cintas de copia de seguridad (si es que se dispone de alguna) en busca de archivos de registro sin manipular es una buena idea. Los archivos de registro son habitualmente modificados por los intrusos para eliminar cualquier rastro de su intrusion, pero en cualquier caso deben ser examinados en busca de eventos “extraños”. Puede que descubra a un intruso intentando obtener acceso, o aprovecharse de un fallo en un programa para obtener acceso como “root”. Es posible que encuentre entradas en los archivos de registro antes de que el intruso tenga tiempo de modificarlos. Deberia asegurarse tambien de separar los registros generados por el servicio auth del resto de la informacion de registro, incluyendo los intentos de utilizacion del comando su, intentos de “login”, etc. Si es posible, configure el syslog para que envie una copia de la informacion de registro mas importante a un sistema seguro. Esto evitara que un intruso borre su rastro de los archivos de registro. Vea la pagina de manual de syslog, concretamente la opcion “@”. Hay por ahi programas syslog mas avanzados. Visite la direccion: http://www.core-sdi.com/ssyslog/ para obtener informacion sobre el Secure Syslog. Este programa le permite encriptar la informacion de registro y asegurarse de que nadie la manipule.

Otro demonio syslog con mas opciones es syslog-ng. Le permite una gran flexibilidad en los registros y tambien se pueden enviar a maquinas remotas para prevenir su manipulacion. Para terminar, decir que los archivos de registro son inutiles si nadie los lee. Dedique periodicamente algun tiempo a examinarlos, y familiaricese con el aspecto que presentan en un uso normal de la maquina. Saber esto puede ayudarle a detectar eventos poco usuales.

9.5. Aplique todas las actualizaciones del sistema que le sea posible. La mayoria de los usuarios de Linux lo instalan desde un CD-ROM. Debido a la rapidez con la que aparecen los parches de seguridad, es casi seguro que para cualquier distribucion en CD-ROM que pretendamos instalar existen parches de seguridad. Antes de conectar la maquina a la red, es una buena idea visitar la pagina “web” de la distribucion en busca de los posibles parches pertinentes. Deberia descargarlos e instalarlos.

10. Que hacer durante y despues de una intrusion ¿Asi que ha seguido algunos de los consejos de este documento (o de cualquier otra parte) y ha detectado una intrusion en su sistema? La primera cosa que debe hacer es mantener la calma. Las acciones precipitadas pueden causar mas daño que el propio intruso.

10.1. Compromisos de la seguridad en curso. Descubrir un compromiso de seguridad en curso puede ser el comienzo de una tarea estresante. El como se reaccione puede tener grandes consecuencias. Si el compromiso de seguridad que se esta viendo es contra la seguridad fisica, posiblemente se trate de que ha visto a alguien introduciendose ilegalmente en su casa, oficina o laboratorio. Deberia avisar a las autoridades locales. En un laboratorio, puede que haya visto a alguien intentando abrir una carcasa o reiniciar una maquina. Dependiendo de la autoridad que se ostente, y de cual sea el procedimiento habitual a seguir en estos casos, puede que deba usted pedir al intruso que deje de hacerlo, o contactar con el personal de seguridad de su empresa. Si ha detectado a un usuario local intentando comprometer la seguridad de su sistema, lo primero que debe hacer es comprobar que se trata en realidad de la persona que usted cree. Compruebe desde donde se esta conectando. ¿Es desde normalmente lo hace? ¿no? entonces utilice alguna forma no electronica para ponerse en contacto con el. Por ejemplo, llamele por telefono o vaya a su casa/oficina y hable con el. Si le confirma que era el quien estaba conectado, puede entonces pedirle que le explique que es lo que estaba haciendo o decirle que deje de hacerlo. Si no estaba conectado, o no sabe de que le esta usted hablando, es muy posible que el incidente necesite una

investigacion mas profunda. Recopile toda la informacion que le sea posible antes de hacer ninguna acusacion. Si ha detectado un compromiso en la seguridad de red, lo primero que debe hacer (si es posible) es desconectarse de la red. Si el intruso esta accediendo via modem, desenchufe el cable del modem. Si es via ethernet, desconecte el cable de la tarjeta de red. Esto impedira que el intruso haga mas daño del que ya haya hecho, y para el esto parecera mas un problema de red que una deteccion. Si no puede desconectarse de la red (porque se trate de una maquina que ofrece algun servicio crucial, o por que no se tenga acceso fisico a la maquina) lo siguiente que puede intentar es utilizar algo como un “tcp_wrapper” o el cortafuegos del kernel (ipchains, ipfwadm) para impedir el acceso desde la maquina del atacante. Si no puede denegar el acceso a todos los usuarios de la maquina desde la que se esta produciendo el ataque, bloquear la cuenta del intruso puede funcionar. Recuerde que bloquear una cuenta no es cosa facil. Debe tener en cuenta los archivos .rhosts, el acceso FTP y todo un ejercito de posibles puertas traseras. Despues de tomar alguna de las medidas anteriores (desconectar de la red, denegar el acceso desde la maquina atacante y/o deshabilitar su cuenta) sera necesario que “mate” todos los procesos de ese usuario. Deberia monitorizar cuidadosamente su sistema durante los minutos siguientes, ya que es muy posible que el atacante vuelva a intentarlo, tal vez usando una cuenta de usuario diferente e incluso una direccion IP distinta.

10.2. El compromiso de seguridad ya ha sucedido Ha detectado usted un compromiso de seguridad que ya ha terminado, o bien ha detectado uno en curso y lo ha abortado siguiendo los consejos anteriores. ¿Y ahora que?

10.2.1. Cerrando el Agujero Si puede determinar que metodo ha usado el intruso para acceder a su sistema, deberia intentar cerrar ese agujero. Por ejemplo, tal vez descubra varios accesos FTP justo antes de que el intruso entrase. Desabilite el servicio FTP e intente conseguir una version actualizada. Compruebe todos sus archivos de registro, y haga una visita a sus paginas “web” de seguridad favoritas para ver si existe algun nuevo agujero que pueda usted tapar. Puede encontrar los parches de seguridad de Caldera en: http://www.caldera.com/tech-ref/security/ Red Hat todavia no ha separado sus parches de seguridad de los parches ordinarios de correccion de errores, pero la lista de fallos de sus distribuciones estan disponibles en la direccion: http://www.redhat.com/errata Debian mantiene una lista de correo y una pagina “web” relativas a la seguridad. Para mas informacion, visite: http://www.debian.com/security/

Es muy posible que si un distribuidor de Linux suministra actualizaciones de seguridad, los demas tambien lo hagan. Hay un proyecto de auditoria de seguridad para Linux. Estan verificando sistematicamente todos los programas de usuario en busca de posibles agujeros de seguridad. Extraido del documento donde se dan a conocer: “Estamos realizando una auditoria sistematica de los codigos fuente de Linux con vistas a hacerlo tan seguro como el OpenBSD. Ya hemos descubierto (y corregido) algunos problemas, pero cualquier ayuda es bienvenida. Nuestra lista de correo es una fuente util de informacion general sobre seguridad. La direccion es [email protected], y para suscribirse debe enviar un “e-mail” a: [email protected]” Si no tapa el agujero que ha usado el atacante, probablemente volvera. No necesariamente a la misma maquina, sino a cualquier otra de su red. Si el intruso ejecuto un “sniffer” de paquetes, es casi seguro que dispone de acceso a otras maquinas de su red.

10.2.2. Evaluando los daños. Es importante realizar una evaluacion del daño causado por el intruso. ¿Que es lo que se ha visto comprometido? si dispone de un verificador de integridad como Tripwire, puede usarlo para realizar una comprobacion. Si no, tendra que revisar usted mismo toda la informacion importante. Como los sistemas Linux se estan volviendo cada vez mas faciles de instalar, puede considerar la opcion de salvar sus archivos de configuracion y borrar totalmente el contenido de los discos duros para volver a instalar todo. Despues solo tendria que restaurar los archivos de configuracion y los datos de usuario. Esto le daria la seguridad de tener un nuevo sistema totalmente “limpio”. Si conserva alguna copia de seguridad del sistema que se ha visto comprometido, sea especialmente cuidadoso con los ejecutables que restaura, ya que puede que haya algun “caballo de troya” dejado por el intruso. Una reinstalacion de este tipo deberia ser obligatoria si se ha detectado una intrusion en la que el atacante haya conseguido privilegios de “root”. Tambien puede que usted desee conservar cualquier evidencia de la intrusion, de manera que no estaria de mas reinstalar en un disco duro diferente y conservar el antiguo tal y como quedo despues del ataque. Despues debe averiguar cuanto tiempo hace que sucedio el ataque, y si las copias de seguridad contienen informacion ya alterada por el intruso. Hablaremos de nuevo sobre las copias de seguridad mas adelante.

10.2.3. Copias de seguridad, copias de seguridad, copias de seguridad! Realizar copias de seguridad periodicamente es un mandato divino por motivos de seguridad. Si su sistema se ve comprometido, puede restaurar la informacion que necesite de las copias de seguridad. Por supuesto, puede que alguna informacion

tenga valor tambien para el atacante, que no solo la destruira si no que la robara y tendra su propia copia, pero al menos usted todavia dispondra de ella. Deberia verificar las copias de seguridad mas recientes antes de restaurar desde ellas algun archivo que haya sido eliminado o modificado por un intruso. Puede que el ataque se perpetrara hace tiempo, con lo cual las copias de seguridad mas recientes no serian de utilidad por contener archivos ya manipulados. Por supuesto, hay mucho mas que decir con respecto a las copias de seguridad. Asegurese de almacenarlas en un lugar seguro. Sepa quien tiene acceso a ellas. Si un intruso consigue una de sus copias de seguridad, tendra acceso a toda su informacion sin que usted jamas se entere.

10.2.4. Rastreando al intruso. Bueno, ya ha expulsado al intruso, tapado el agujero y restaurado su sistema, pero todavia no esta todo hecho. Aunque en la mayoria de los casos no existen muchas posibilidades de echar el guante al atacante, deberia informar del ataque. Deberia informar de los hechos al administrador del sistema desde el que el ataque fue perpetrado. Puede averiguar con quien debe contactar mediante el uso del servicio whois o consultando la base de datos Internic. Podria enviarles un correo electronico adjuntando la informacion referente al ataque que haya encontrado en los archivos de registro. Seria buena idea contactar tambien por telefono. Con la informacion facilitada por usted, ese administrador puede rastrear al intruso y averiguar desde que sistema se conecto con ellos, repitiendo la operacion con el otro administrador, y asi sucesivamente. Los “crackers” competentes casi siempre utilizan multiples sistemas intermediarios hasta llegar a su maquina, algunos (o muchos) de los cuales ni siquiera saben que han sido utilizados para ello. Intentar rastrear a un intruso hasta su casa puede ser dificil. Ser educado con los administradores con los que trate puede ser conveniente si desea conseguir que le ayuden. Si forma parte de alguna organizacion relacionada con la seguridad (CERT o similar) deberia informarles tambien, asi como al suministrador de su sistema Linux.

11. Recursos de Seguridad Existen multitud de lugares donde encontrar informacion relativa a la seguridad de los sistemas Unix en general y tambien especifica de Linux. Es muy importante suscribirse a algunas listas de correo sobre seguridad y mantenerse al corriente de los nuevos parches de seguridad. La mayoria de estas listas generan un volumen de mensajes muy bajo, y son muy instructivas.

11.1. Sitios FTP El CERT (Computer Emergency Response Team) es el Equipo de Respuesta a Emergencias Informaticas. Frecuentemente alertan de ataques de actualidad y proporcionan parches de seguridad. Para mas informacion, visite: ftp://ftp.cert.org

el sitio “web” Replay (http://www.replay.com) permite la descarga de muchos programas de seguridad. Como esta fuera de los EE.UU. no necesita obedecer las restricciones en materia de encriptacion. Matt Blaze es el autor del CFS (Cryptographic File System) y es un gran “consejero” de seguridad. Para mas informacion: tue.nl es un gran sitio FTP de seguridad ubicado en Holanda. ftp.win.tue.nl

11.2. Sitios Web • •

•

“The Hacker FAQ” es un FAQ sobre hackers (N. del T: no se dice donde encontrar este documento). El archivo COAST tiene un gran numero de programas de seguridad para Unix y tambien informacion. La Pagina de Seguridad de SuSe: http://www.suse.de/security/

•

Rootshell.com es un lugar muy bueno para ver los “exploits” que estan siendo utilizados actualmente por los “crackers”: http://www.rootshell.com/

• •

BUGTRAQ realiza informes sobre temas de seguridad Dan Farmer es el autor de SATAN y muchas otras herramientas de seguridad. Su “web” contiene tanto herramientas como documentacion. http://www.trouble.org

• •

“Linux Security” es un buen lugar para conseguir informacion relativa a la seguridad con Linux: Linux Security WWW Infilsec dispone de una base de datos con un motor de busqueda que permite consultar vulnerabilidades que afecten a una plataforma especifica. Su direccion es: http://www.infilsec.com/vulnerabilities/

•

CIAC realiza publicaciones periodicas relativas a “exploits” comunes: http://ciac.llnl.gov/cgi-bin/index/bulletins

•

Un buen lugar donde iniciarse en el uso de los modulos PAM es: http://www.kernel.org/pub/linux/libs/pam/

•

El proyecto Debian tiene una pagina “web” con sus parches de seguridad y tambien informacion. La direccion es:

http://www.debian.com/security/ •

El FAQ de Seguridad WWW, escrito por Lincoln Stein, es una gran fuente de informacion de seguridad relativa al servicio WWW: http://www.w3.org/Security/Faq/www-security-faq.html

11.3. Listas de Correo Bugtraq: para suscribirse a bugtraq, envie correo a [email protected] poniendo en el cuerpo del mensaje la frase “subscribe bugtraq”. CIAC: envie correo a [email protected] poniendo en el cuerpo del mensaje la frase “subscribe ciac-bulletin”. Red Hat posee varias listas de correo, de las cuales la mas importante es la lista “redhat-announce”. A traves de ella se suministran los ultimos parches y correcciones, entre ellos los de seguridad. Si desea suscribirse, envie correo a [email protected] con la frase “subscribe redhat-announce”. El proyecto Debian mantiene una lista de correo sobre seguridad que cubre todo lo referente a sus actualizaciones y parches en esta materia. Para mas informacion puede visitar la direccion: http://www.debian.com/security/

11.4. Libros - Material de Lectura Impreso Existen por ahi numerosos libros muy buenos sobre seguridad. Esta seccion hace referencia a algunos de ellos. Ademas de los libros especificos sobre seguridad, este tema tambien es tratado es otros libros cuyo tema central es la administracion de sistemas. Building Internet Firewalls por D. Brent Chapman & Elizabeth D. Zwicky 1ª Edicion Septiembre 1995 ISBN: 1-56592-124-0 Practical UNIX & Internet Security, 2¦ Edicion por Simson Garfinkel & Gene Spafford 2ª Edicion Abril 1996 ISBN: 1-56592-148-8 Computer Security Basics por Deborah Russell & G.T. Gangemi, Sr. 1ª Edicion Julio 1991 ISBN: 0-937175-71-4 Linux Network Administrator’s Guide por Olaf Kirch 1ª Edicion Enero 1995

ISBN: 1-56592-087-2 PGP: Pretty Good Privacy por Simson Garfinkel 1ª Edicion Diciembre 1994 ISBN: 1-56592-098-8 Computer Crime A Crimefighter’s Handbook por David Icove, Karl Seger & William VonStorch (Consulting Editor Eugene H. Spafford) 1ª Edicion Agosto 1995 ISBN: 1-56592-086-4

12. Glosario •

authentication (autentificacion): Es la propiedad de saber que la informacion recibida es la misma que la que fue enviada, y que el remitente real es quien se supone que es.

•

bastion host (maquina bastion): Es un sistema que tiene que estar altamente protegido porque es susceptible de ser atacado, normalmente porque esta expuesto a Internet y es el punto de contacto principal entre los usuarios de la red interna. Recibe su nombre de las paredes exteriores de las antiguos castillos medievales, altamente fortificados. Los bastiones vigilaban puntos criticos defensivos, y normalmente constituian un lugar para poner tropas “extra”, arrojar aceite hirviendo a los atacantes, etc. (N. del T: estas practicas estan totalmente en desuso hoy dia, habiendo sido sustituidas ventajosamente por la ubicacion estrategica de un vendedor de la revista “La Farola”).

•

buffer overflow (desbordamiento de buffer): La forma habitual de programar hoy dia incluye el no asignar nunca “buffers” lo suficientemente grandes, y no comprobar si se desbordan. Cuando un “buffer” se desborda, el programa en ejecucion (por ejemplo, un demonio o un programa SUID) puede ser “engañado” para que haga algo diferente a lo previsto. Esto se consigue generalmente sobreescribiendo la direccion de retorno de una funcion en la pila con una direccion diferente (donde esta el codigo del “cracker”).

•

denial of service (denegacion de servicio): Consiste en un ataque en el que los recursos del sistema (memoria, espacio en disco, etc) son consumidos por un proceso hostil haciendo imposible que puedan ser utilizados por los usuarios legitimos. (N. del T: un ejemplo sencillo de esta tecnica seria enviar a una cuenta de correo de la maquina objetivo un mensaje cuyo tamaño sea mayor que el espacio libre disponible en la particion que aloja al directorio /var/spool/mail. Si el administrador cometio la imprudencia de dejar ese directorio en la particion que alberga el sistema de archivos raiz (/) y ademas no establecio una politica de limitacion de espacio en disco (cuotas) entonces su maquina se quedara sin espacio en disco, viendose afectados todos los servicios que ofrezca).

•

dual-homed host (maquina con hogar dual): Es un ordenador de proposito general que posee al menos dos interfaces de red.

•

firewall (cortafuegos): Es el componente o conjunto de componentes que controla y restringe las comunicaciones entre una red protegida e Internet, o entre cualquier otro conjunto de redes.

•

host (maquina, equipo): Es un ordenador conectado a una red.

•

IP spoofing (usurpacion de direccion IP): Este es un ataque tecnicamente complejo que utiliza multiples componentes. Basicamente consiste en introducirse en un entorno donde existen maquinas que se comunican entre si en base a una “relacion de confianza” y hacer creer a una de estas maquinas que somos una de sus “amigas”. Existe un documento que trata intensivamente este tema escrito por daemon9, route e infinity en el Volumen Siete, numero cuarenta y ocho, de la revista “Phrack”.

•

non-repudiation (imposibilidad de negar la autoria): Esta seria la habilidad que tendria alguien capaz de demostrar que un determinado remitente ha enviado una determinada informacion incluso en el caso de que este remitente niegue posteriormente el haberlo hecho. packet (paquete): Es la unidad fundamental de comunicacion en Internet

• •

packet filtering (filtrado de paquetes): Es la accion mediante la que un dispositivo realiza un control selectivo del flujo de paquetes hacia y desde una red. Los filtros bloquean los paquetes o los dejan pasar, normalmente mientras son enrutados de una red a otra (la nayoria de las veces entre Internet y una red interna). Para que el filtro funcione, se dictan reglas que determinan que tipo de paquetes pueden pasar y cuales son bloqueados.

•

perimeter network (red envolvente): Es una red que separa a una red protegida de otra red externa, con el fin de proporcionar una capa adicional de seguridad. A veces se les llama DMZ.

•

proxy server (servidor proxy): Es un programa que hace de intermediario entre un servidor externo y un cliente interno. Los clientes proxy se comunican con el servidor proxy, el cual remite los accesos que se consideren autorizados al servidor real, devolviendo tambien las respuestas del servidor al cliente correspondiente.

•

superuser (super-usuario): Es un nombre informal para el usuario “root”.

13. Preguntas realizadas con frecuencia (FAQ’s) 1. ¿Es mas seguro compilar el soporte para los dispositivos directamente en el kernel que la utilizacion de modulos? Respuesta: alguna gente piensa que es mejor desabilitar la capacidad del kernel de cargar modulos adicionales, ya que un intruso podria cargar un modulo troyano o uno para alterar la seguridad del sistema. En cualquier caso, para poder cargar modulos se necesitan privilegios de “root”. Los archivos objeto de los modulos tampoco pueden ser modificados por nadie salvo el superusuario. De esto se deduce que un intruso necesita acceso de “root” para poder cargar modulos. Si un intruso obtiene acceso de “root” hay cosas mas serias de las que preocuparse que de si carga un modulo. Los modulos son para permitir la carga dinamica del soporte para un dispositivo que no se usa frecuentemente. En maquinas servidor, como un cortafuegos por ejemplo, es muy raro que esto sea necesario. Por esta razon, es mas logico compilar directamente en el kernel el soporte para los dispositivos que esa maquina servidor vaya a utilizar. Ademas, los modulos son mas lentos que el soporte directo en el kernel.

2. ¿Por que no se puede hacer “login” como “root” desde una maquina remota? Respuesta: vease “seguridad de root”. Esto sucede de forma intencional para evitar que se pueda intentar conectar via telnet como “root”, lo que es un riesgo importante para la seguridad. No lo olvide: los intrusos potenciales tienen al tiempo de su parte, y pueden ejecutar programas automatizados de busqueda de contraseñas.

3. etc?

¿Como habilito el uso de “shadow passwords” en mi Red Hat 4.2, 5.x,

Respuesta: el “shadow password” es un mecanismo que permite almacenar las contraseñas en otro archivo que no sea el tipico /etc/passwd. Esto proporciona varias ventajas. La primera es que dicho archivo solo es legible por “root”, a diferencia de /etc/passwd, que debe ser de publica lectura. La otra ventaja es que el administrador puede habilitar y deshabilitar cuentas sin que todo el mundo pueda saber el estado de estas. El archivo /etc/passwd es utilizado para almacenar los nombres de los usuarios y los grupos, utilizados por programas como /bin/ls para mapear los ID de usuario con los nombres correspondientes al mostrar el contenido de un directorio. El archivo /etc/shadow solo contiene el nombre del usuario y su contraseña encriptada, y tal vez informacion de contabilidad, como la fecha de expiracion de la cuenta, etc.

Para habilitar el uso del “shadow password”, ejecute “pwconv” como “root”, asegurandose antes de que no existe /etc/shadow ni esta siendo utilizado por ninguna aplicacion. Si utiliza RedHat 4.2 o superior, los modulos PAM se adaptaran automaticamente a este cambio sin ninguna otra modificacion. Si esta interesado en hacer que sus contraseñas sean mas seguras, tal vez desee generar unas buenas contraseñas con las que empezar. Para esto puede usar el modulo pam_cracklib, que forma parte del paquete PAM. Este modulo realiza un intento de “crackear” sus contraseñas para ayudarle a decidir si son facilmente obtenibles para los programas de busqueda de contraseñas.

4.

¿Como puedo habilitar las extensiones SSL de Apache? Respuesta: 1.Consiga SSLeay 0.8.0 o superior de 2.Compile, pruebe e instale 3.Consiga los fuentes de Apache 1.2.5 (o superior) 4.Consiga las extensiones SSLeay de Apache en 5.Desempaquete en el directorio de los fuentes de Apache y parchee tal y como se explica en el archivo README 6.Configure y compile Puede tambien visitar el sitio “web” de Replay Associates, donde puede encontrar muchos paquetes precompilados, y ademas estan fuera de los Estados Unidos.

5. ¿Como puedo manipular las cuentas de usuario manteniendo la seguridad? Respuesta: la distribucion RedHat contiene un gran numero de herramientas para modificar las propiedades de las cuentas de usuario. • • • •

Los programas pwconv y unpwconv pueden utilizarse para habilitar o deshabilitar el uso de “shadow password”. Los programas pwck y grpck pueden usarse para verificar que los archivos passwd y group esten correctamente organizados. Los programas useradd, usermod y userdel permiten agregar, eliminar y modificar cuentas de usuario. Los comandos groupadd, groupmod y groupdel hacen lo mismo con los grupos. Las contraseñas de grupo pueden crearse con el comando gpasswd Todos estos programas son lo suficientemente “inteligentes” como para saber si el sistema usa o no “shadow password” y adaptarse a esta contingencia. Consulte las paginas de manual correspondientes si desea ampliar su informacion sobre estos comandos.

6. ¿Como puedo proteger con contraseña documentos HTML especificos usando Apache? Apuesto a que no conoce http://www.apacheweek.org, ¿a que no? Puede encontrar informacion sobre la autentificacion de usuarios en: http://www.apacheweek.com/features/userauth Asi como algunos otros consejos de seguridad en: http://www.apache.org/docs/misc/security_tips.html

14.

Conclusion

Solo con suscribirse a las listas de correo de alertas de seguridad y manteniendo actualizados los programas, ya estara dando un gran paso hacia el objetivo de hacer que su sistema sea seguro. Si examina atentamente los archivos de registro con cierta periodicidad y ejecuta algo como tripwire regularmente, estara haciendo mucho mas. Un nivel de seguridad razonable no es dificil de mantener en una maquina domestica. Para un sistema en un entorno de negocio se requiere mas esfuerzo, pero Linux puede ser una plataforma bastante segura. Debido a la naturaleza del desarrollo de Linux, los parches de seguridad son creados con mayor rapidez que en otros entornos, haciendo que Linux sea una plataforma ideal cuando la seguridad sea un requisito indispensable.

15. Agradecimientos: (N. del T: como suele ser mi costumbre, esta seccion permanece en el idioma original) Information here is collected from many sources. Thanks to the following that either indirectly or directly have contributed: following who either indirectly or directly have contributed: Rob Riggs [email protected] S. Coffin [email protected] Viktor Przebinda [email protected] Roelof Osinga [email protected] Kyle Hasselbacher [email protected] David S. Jackson [email protected] Todd G. Ruskell [email protected] Rogier Wolff [email protected] Antonomasia [email protected] Nic Bellamy [email protected] Eric Hanchrow [email protected]

Robert J. [email protected] Ulrich Alpers [email protected] David Noha [email protected]

The following have translated this HOWTO into various other languages! A special thank you to all of them for help spreading the linux word... Polish: Ziemek Borowski [email protected] Japanese: FUJIWARA Teruyoshi [email protected] Indonesian: Tedi Heriyanto [email protected] Traducido al castellano por Juan Carlos Fernandez del equipo de “Aebius. Centro de Linux” entre Septiembre y Octubre de 1999