Preparación para el examen de LPI: Seguridad de sistemas

Administración Nivel Intermedio (LPIC-2), Tema 212

Este tutorial, el sexto de una serie de siete tutoriales cubre la administración de redes de nivel intermedio en Linux.® David Mertz continúa preparándolo para rendir el Examen 202 de Intermediate Level Administration del Linux Professional Institute® (LPIC-2). Este tutorial debe cubrir una gran variedad de temas relacionados con Linux, lo cuales se explicarán brevemente desde la perspectiva de un servidor de redes con medidas de seguridad. Este tutorial desarrollará los aspectos generales de ruteo, firewalls y traducción NAT con sus respectivas herramientas de gestión. Además, explicará cómo configurar políticas de seguridad para FTP y SSH; describirá el control general de acceso con tcpd, hosts.allow y friends; presentará una serie de herramientas básicas de monitoreo de la seguridad y mostrará dónde encontrar recursos de seguridad.

David Mertz, Developer, Gnosis Software, Inc.

David Mertz cree que los lenguajes artificiales son perfectamente naturales pero los lenguajes naturales parecen un poco artificiales. Es posible contactar a David en mertz@gnosis.cx; podrá investigar todos los aspectos de su vida en su página Web personal. Vea su libro, Text Processing in Python (Procesamiento de Texto en Python). Las sugerencias y recomendaciones sobre las columnas pasadas o futuras son bienvenidas.



29-07-2011

Antes de comenzar

Conozca lo que puede aprender leyendo estos tutoriales y sepa cómo aprovecharlos al máximo.

Acerca de esta serie

Linux Professional Institute (LPI) otorga certificaciones de administrador de sistemas Linux de dos niveles: nivel junior (también denominado "certificación nivel 1") y nivel intermedio (también denominado "certificación nivel 2"). Para obtener la certificación nivel 1, deberá aprobar los exámenes 101 y 102; para obtener la certificación nivel 2, deberá aprobar los exámenes 201 y 202.

developerWorks ofrece tutoriales para ayudarlo a prepararse para los cuatro exámenes. Cada examen cubre una serie de temas y developerWorks ofrece un tutorial de autoestudio para cada uno de ellos. A continuación, se detallan los siete temas del examen 202 de LPI y sus correspondientes tutoriales developerWorks:

Tabla 1. Examen 202 de LPI: Tutoriales y temas
Tema de examen 202 de LPITutorial developerWorksResumen del tutorial
Tema 205Preparación para el examen 202 de LPI (tema 205):
Configuración de redes
Aprenda a configurar una red TCP/IP básica desde el nivel de hardware (generalmente Ethernet, módem, ISDN o 802.11) hasta el ruteo de direcciones de red.
Tema 206Preparación para el examen 202 de LPI (tema 206):
Correspondencia y noticias
Aprenda a usar Linux como servidor de correspondencia y como servidor de noticias. Aprenda acerca de transporte de correspondencia, filtrado de correspondencia local, software de mantenimiento de listas de correspondencia y software de servidores para el protocolo NNTP.
Tema 207Preparación para el examen 202 de LPI (tema 207):
DNS
Aprenda a usar Linux como servidor DNS, principalmente usando BIND. Aprenda a realizar una configuración BIND básica, gestionar zonas DNS y proteger servidores DNS.
Tema 208Preparación para el examen 202 de LPI (tema 208):
servicios web
Aprenda a instalar y configurar el servidor Web Apache y a implementar el servidor proxy Squid.
Tema 210Preparación para el examen 202 de LPI (tema 210):
Gestión de clientes de red
Aprenda a configurar un servidor DHCP, un cliente y un servidor NIS, un servidor LDAP y el soporte de autenticaciones PAM. Vea los objetivos detallados a continuación.
Tema 212Preparación para el examen 202 de LPI (tema 212):
Seguridad de sistemas
(Este tutorial) Aprenda a configurar un router, proteger servidores FTP, configurar SSH y realizar otras tareas de administración de la seguridad. Vea los objetivos a continuación.
Tema 214Preparación para el examen 202 de LPI (tema 214):
Solución de problemas de redes
Próximamente

Para comenzar a prepararse para la certificación nivel 1, consulte los tutoriales developerWorks para el examen 101 de LPI. Para prepararse para otro examen de la certificación nivel 2, consulte los tutoriales developerWorks para el examen 201 de LPI. Lea más acerca de la serie completa de tutoriales developerWorks LPI.

Linux Professional Institute no patrocina ningún material ni técnica de preparación para exámenes de terceros en particular. Para obtener más información, escriba a info@lpi.org.

Acerca de este tutorial

Bienvenido a "Seguridad de sistemas", el sexto de una serie de siete tutoriales acerca de la administración de redes de nivel intermedio en Linux. En este tutorial, aprenderá acerca de una amplia gama de temas relacionados con el uso de Linux como servidor de redes con medidas de seguridad. Se cubrirán temas tales como el ruteo, los firewalls y la traducción NAT (y las herramientas necesarias para gestionarlos) y el establecimiento de políticas de seguridad para FTP y SSH. También aprenderá a usar el control general del acceso con tcpd, hosts.allow y friends (retomando lo explicado en el tutorial Preparación para el examen 201 de LPI (tema 209): Compartir archivos y servicios). Por último, conocerá algunas herramientas básicas de monitoreo de la seguridad y sabrá dónde encontrar recursos de seguridad.

Al igual que otros tutoriales de las series developerWorks 201 y 202, el presente tutorial debe considerarse como una guía de estudio y un punto de partida para la preparación de exámenes y no como la documentación completa sobre el tema. Se recomienda al lector consultar la lista detallada de objetivos de LPI y complementar la información provista en este tutorial con otros materiales, de acuerdo con las necesidades.

Este tutorial está organizado en base a los objetivos LPI de este tema. Como regla general, el examen incluirá más preguntas sobre los objetivos con mayor valor.

Tabla 2. Seguridad de sistemas: Objetivos del examen cubiertos en este tutorial
Objetivo del examen de LPIValor de ponderación del objetivoResumen del objetivo
2.212.2
Configuración de un router
Valor: 2Configurar un sistema para la traducción de direcciones de redes (NAT, enmascaramiento de IP) y comprender su importancia para la protección de redes. Este objetivo incluye: configuración de redireccionamiento de puertos, gestión de reglas de filtrado y prevención de ataques.
2.212.3
Protección de servidores FTP
Valor: 2Configurar un servidor FTP para realizar descargas y cargas anónimas. Este objetivo incluye: precauciones que deben tomarse al permitir las cargas anónimas y configuración del acceso de usuarios.
2.212.4
Shell seguro (SSH)
Valor: 2Configurar un daemon SSH. Este objetivo incluye: gestión de claves, configuración de SSH para usuarios, reenvío de protocolos de aplicaciones sobre SSH y gestión del inicio de sesión SSH.
2.212.5
TCP_wrappers
Valor: 1Configurar tcpwrappers para permitir conexiones con servidores especificados exclusivamente de ciertos hosts o subredes.
2.212.6
Tareas de seguridad
Valor: 3Instalar y configurar un sistema de autenticación protegido; realizar auditoria básica de seguridad de código fuente; recibir alertas de seguridad de distintas fuentes; auditar servidores para relés abiertos de correspondencia y servidores FTP; instalar, configurar y ejecutar sistemas de detección de intrusiones; y aplicar parches de seguridad y arreglos de errores.

Requisitos previos

Para aprovechar al máximo este tutorial, deberá contar con conocimientos básicos de Linux y con un sistema Linux en funcionamiento donde pueda practicar los comandos aquí explicados.

Otros recursos

Al igual que con la mayoría de las herramientas Linux, se recomienda consultar las páginas man de las utilidades abordadas. Las versiones y switches podrían diferir en las versiones de utilidad y del kernel o entre distintas distribuciones de Linux. Si desea obtener información más detallada, el Proyecto de documentación Linux ofrece una gran variedad de documentos útiles, especialmente los artículos instructivos. Además, hay publicados varios libros sobre la seguridad del sistema Linux. Personalmente, TCP/IP Network Administration de O'Reilly, por Craig Hunt me resultó de gran utilidad. Encuentre los vínculos a estos documentos en la sección de Recursos.


Configuración de un router

Acerca del filtrado de paquetes

El kernel Linux incluye la infraestructura "netfilter", la cual permite filtrar paquetes de red. Generalmente, esta capacidad se encuentra compilada dentro del kernel de base; sin embargo, podría requerirse un módulo de kernel. En ambas formas, la carga de módulos se llevará a cabo sin contratiempos (por ejemplo, ejecutar iptables cargará iptables_filter.o de necesitarlo).

Los sistemas Linux más modernos controlan el filtrado de paquetes mediante la utilidad iptables; los sistemas más antiguos usan ipchains y, anteriormente, se usabaipfwadm. Si bien la compatibilidad con versiones anteriores permite usar ipchains junto con los kernels más recientes, siempre se preferirán las capacidades y la sintaxis mejoradas que ofrece iptables. Por otra parte, la mayoría de los conceptos y switches de iptables son mejoras compatibles con ipchains.

Dependiendo del escenario de filtrado en particular (firewall, NAT, etc.), el filtrado y la traducción de direcciones podrían suceder antes o después del ruteo en sí. Si bien en ambos casos se usa la herramienta ipchains, en cada uno se aplican diferentes conjuntos de reglas ("cadenas"); a nivel básico: INPUT y OUTPUT. Además, el filtrado también podría afectar la decisión de ruteo filtrando en la cadena FORWARD; esto podría provocar que se eliminen paquetes, en lugar de que sean ruteados.

Ruteo

Además de efectuar el filtrado con iptables (o ipchains de legado), el kernel Linux rutea los paquetes IP que recibe. Si bien ambos procesos se relacionan conceptualmente, el ruteo es más sencillo que el filtrado.

Durante el ruteo, el host simplemente toma una dirección de IP de destino y define si entregará el paquete directamente a la dirección o si se encuentra disponible una puerta de enlace para entregar directamente el paquete a la dirección. Si el host no puede entregar el paquete por sí mismo ni encuentra una puerta de enlace disponible para reenviarlo, el paquete se elimina. Sin embargo, las configuraciones típicas incluyen una "puerta de enlace predeterminada " que administra todas las direcciones no especificadas.

La configuración y visualización de la información de ruteo se lleva a cabo con la utilidad route. El ruteo podría ser estático o dinámico.

En el ruteo estático, la entrega se determina mediante una tabla de ruteo explícitamente configurada mediante invocaciones del comando route y sus comandos add o del. En el caso del ruteo dinámico, es más común que la configuración se efectúe usando los daemons routed o gated que transmiten información de ruteo a daemons de ruteo adyacentes.

El daemon routed soporta Routing Information Protocol (RIP); mientras que el daemon gated suma el soporte de varios protocolos (el usuario puede usar varios protocolos al mismo tiempo) como:

  • Routing Information Protocol Next Generation (RIPng)
  • Exterior Gateway Protocol (EGP)
  • Border Gateway Protocol (BGP) y BGP4+
  • Defense Communications Network Local-Network Protocol (HELLO)
  • Open Shortest Path First (OSPF)
  • Intermediate System to Intermediate System (IS-IS)
  • Internet Control Message Protocol (ICMP y ICMPv6)/Router Discovery

Primero analicemos una tabla de ruteo estático típica:

Listado 1. Tabla de ruteo estático típica
% /sbin/route Kernel IP routing
table Destination Gateway Genmask Flags Metric Ref Use Iface 66.98.217.0 *
255.255.255.0 U 0 0 0 eth0 10.10.12.0 * 255.255.254.0 U 0 0 0 eth1 66.98.216.0 *
255.255.254.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth1 default
ev1s-66-98-216- 0.0.0.0 UG 0 0 0 eth0

Esta tabla indica que las direcciones de los rangos 66.98.217/24 y 66.98.216/23 se entregarán directamente sobre eth0. Los rangos de direcciones 10.10.12/23 y 169.254/16 se entregarán sobre eth1. Todos los elementos restantes se enviarán mediante una puerta de enlace ev1s-66-98-216-1.ev1servers.net (el nombre aparece cortado en la pantalla route; use route -n y verá que el nombre de la dirección de IP es 66.98.216.1). Si quisiera agregar una puerta de enlace distinta para otros rangos de direcciones, podría ejecutar algo similar al Listado 2:

Listado 2. Agregar puerta de enlace nueva para otros rangos de direcciones
%
route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.2.1 dev eth0

En una máquina que actúa como puerta de enlace en sí misma, se recomienda ejecutar ruteo dinámico usando los daemons routed o gated, lo cual puede suplementar una menor cantidad de rutas estáticas. El daemon routed está configurado con el contenido de /etc/gateways. El daemon gated es más moderno y cuenta con más capacidades (como se señaló anteriormente); este último daemon está configurado con /etc/gated.conf. Para usar ambos daemons, se recomienda iniciarlos en los scripts de inicio. Nunca ejecute routed y gated en la misma máquina, porque los resultados serán impredecibles y seguramente indeseables.

Filtrado con iptables

El kernel Linux almacena una tabla de reglas de filtrado de paquetes IP que forma una especie de máquina de estados. Los conjuntos de reglas que se procesan en secuencia se denominan "cadenas (de firewall)". Cuando una cadena cumple con una condición, una acción posible es que el control pase al procesamiento de otra cadena, como sucedería en una máquina de estados. Antes de agregar cualquier regla o estado, existen tres cadenas creadas automáticamente: INPUT, OUTPUT y FORWARD. Por la cadena INPUT se transmiten paquetes direccionados a la máquina host que posiblemente luego pasarán a un proceso de una aplicación local. Por la cadena FORWARD se transmiten paquetes direccionados a otra máquina, suponiendo que el reenvío se encuentre activado y que el sistema de ruteo conozca cómo reenviar el paquete en cuestión. Los paquetes generados en el host local se envían a la cadena OUTPUT para su filtrado. Si el paquete pasa los filtros de la cadena OUTPUT (o de cadenas vinculadas), se ruteará sobre la interfaz de red correspondiente.

Una regla puede generar la eliminación de un paquete (DROP). En este caso, finaliza el procesamiento por reglas y la transición de estados del paquete. De lo contrario, si el paquete no es eliminado, se verificará si coincide con la siguiente regla de la cadena. En algunas ocasiones, el cumplimiento de la regla ramifica el proceso hacia otra cadena con su respectivo conjunto de reglas. La creación, eliminación o modificación de reglas y cadenas que contienen reglas se efectúa mediante la herramienta iptables. En sistemas Linux más antiguos, esta función se realizaba mediante ipchains. Los conceptos en los que se basan ambas herramientas y el más antiguo ipfwadm son similares, pero en este tutorial desarrollaremos la sintaxis de iptables.

Cada regla especifica un conjunto de condiciones a cumplir por los paquetes y las acciones que deben llevarse a cabo si un paquete no cumple con las condiciones. Como mencionamos anteriormente, una acción común es la eliminación de paquetes con DROP. Por ejemplo, supongamos que, por cualquier razón, deseamos desactivar ping en la interfaz de bucle invertido (interfaz ICMP). Esto será posible de la siguiente manera:

Listado 3. Desactivación en la interfaz de bucle invertido
% iptables -A INPUT
-s 127.0.0.1 -p icmp -j DROP

Como esta regla no tiene demasiada utilidad, luego de probarla la eliminaremos de la siguiente manera:

Listado 4. Eliminación de la regla
% iptables -D INPUT -s 127.0.0.1 -p icmp -j
DROP

Para eliminar la regla con la opción -D deberá ingresar exactamente las mismas opciones que especificó al agregarla o bien indicar el número de regla (que debe determinar previamente) de la siguiente manera:

Listado 5. Especificación de un número de regla para permitir la eliminación
%
iptables -D INPUT 1

Otra regla que tendría mayor utilidad podría analizar las direcciones de origen y destino de los paquetes. Por ejemplo, supongamos que una red remota problemática intentase utilizar servicios de una determinada subred de su red. Podrá bloquearla en su máquina de firewall/ puerta de enlace de la siguiente forma:

Listing 6. Bloqueo de máquina de firewall/ puerta de enlace
% iptables -A
INPUT -s 66.98.216/24 -d 64.41.64/24 -j DROP

Esta acción impedirá que cualquier elemento del bloque de IP 66.98.216.* se comunique con cualquier elemento de la subred local 64.41.64.*. Desde ya, proteger un bloque de IP en particular resultaría una protección demasiado limitada. Un ejemplo más real sería permitir el acceso a la subred local únicamente a un bloque de IP específico:

Listado 7. Permitir el acceso a la subred local a un bloque de IP específico
%
iptables -A INPUT -s ! 66.98.216/24 -d 64.41.64/24 -j DROP

En este caso, únicamente el bloque de IP 66.98.216.* puede acceder a la subred especificada. También es posible darle un nombre simbólico a la dirección y especificar un protocolo en particular para filtrar. Otra posibilidad es seleccionar una interfaz de red específica (por ejemplo: eth0) para filtrar, aunque esta última alternativa no resulta tan útil. Por ejemplo, el Listado 8 muestra como permitir a una única red remota acceder a un servidor Web local:

Listado 8. Permitir a una única red remota acceder a un servidor Web local
%
iptables -A INPUT -s ! example.com -d 64.41.64.124 -p TCP -sport 80 -j
DROP

Con iptables es posible especificar otras opciones tales como establecer límites de cantidad de paquetes permitidos o filtrar indicadores TCP. Para obtener más información, consulte las páginas man de iptables.

Cadenas definidas por el usuario

Hemos visto las nociones básicas para agregar reglas a las cadenas automáticas. Sin embargo, donde más se observa la configurabilidad de iptables es en el agregado de cadenas definidas por el usuario y en la ramificación ante la coincidencia de los patrones incluidos en ellas. Las cadenas nuevas se definen con la opción -N; antes vimos una ramificación usando el objetivo especial DROP. Otro objetivo especial es ACCEPT que, como su nombre lo indica, se usa para aceptar. También se encuentran disponibles los objetivos especiales RETURN y QUEUE. El primero permite detener el procesamiento de una cadena en particular y devolverla a su llamante original. El administrador de colas de QUEUE permite transmitir paquetes a un proceso del espacio del usuario para continuar con su procesamiento (registro, modificación del paquete o filtrado de mayor complejidad al que soporta iptables). El ejemplo simple incluido en el instructivo "Linux 2.4 Packet Filtering HOWTO" [Filtrado de paquetes en Linux 2.4] de Rusty Russell es una buena demostración de cómo agregar una cadena definida por el usuario:

Listado 9. Agregar una cadena definida por el usuario
# Create chain to block
new connections, except established locally % iptables -N block % iptables -A
block -m state --state ESTABLISHED,RELATED -j ACCEPT % iptables -A block -m
state --state NEW -i ! ppp0 -j ACCEPT % iptables -A block -j DROP # DROP
everything else not ACCEPT'd # Jump to that chain from INPUT and FORWARD chains
% iptables -A INPUT -j block % iptables -A FORWARD -j block

Observe que la cadena block acepta (con ACCEPT) una clase de casos limitada y luego la regla final elimina (con DROP) todos los elementos que no fueron aceptados.

Después de establecer algunas cadenas, ya sea agregando reglas a las cadenas automáticas o agregando cadenas definidas por el usuario, puede usar la opción -L para visualizar la reglas actuales.

Traducción de Dirección de Red versus firewalls

Los ejemplos vistos hasta ahora incluyeron principalmente reglas de firewall. Pero iptables también configura la Traducción de Dirección de Red (Network Address Translation – NAT).

Básicamente, NAT es una forma de usar el seguimiento de conexiones para enmascarar paquetes que provienen de una dirección de subred local, como direcciones WAN externas, antes de enviarlos "a través de la línea" (en la cadena OUTPUT). La puerta de enlace /el router que realiza la NAT debe recordar el host local conectado y el host remoto con el que se conectó y revertir la traducción de direcciones si los paquetes vuelven del host remoto.

Sin embargo, desde el punto de vista del filtrado, es como si la NAT no existiese. Las reglas que especifiquemos simplemente usarán las direcciones "reales" locales, independientemente del enmascaramiento que realiza la NAT para el exterior. Para activar el enmascaramiento, al igual que en NAT básica, use el comando iptables. Para esto, deberá asegurarse de que el módulo del kernel iptables_nat se encuentra cargado y que el reenvío de IP se encuentre activado:

Listado 10. Activar el enmascaramiento
% modprobe iptables_nat # Load the
kernel module % iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE % echo 1
> /proc/sys/net/piv4/ip_forward # Turn on IP forwarding

Esta capacidad se denomina NAT de origen y modifica la dirección del paquete saliente. También existe NAT de destino (DNAT) que ofrece reenvío de puertos, cargas compartidas y proxy transparente. En estos casos, los paquetes entrantes se modifican para que lleguen al host local o la subred correspondiente.

En general, cuando los usuarios o administradores hablan de NAT, se refieren a NAT origen. Si usted desea configurar NAT destino, deberá especificar PREROUTING en lugar de POSTROUTING. Con DNAT, los paquetes se transforman antes de rutearse.


Protección de servidores FTP

Servidores FTP

Existen una gran variedad de servidores FTP para Linux y las distintas distribuciones ofrecen diferentes servidores. Evidentemente, la configuración de los distintos servidores varía, aunque la mayoría tienden a seguir directivas de configuración similares.

Un servidor FTP popular es vsftpd (Very Secure FTP daemon). Otros servidores muy difundidos son ProFTP, wu-ftpd y ncftpd.

En muchos casos no es necesario usar FTP. Por ejemplo, las transferencias seguras entre usuarios con cuentas en una máquina de servidor pueden efectuarse mediante scp (secure copy – copia segura), que usa la instalación SSH subyacente y, en la mayoría de los casos, simplemente imita al comando cp.

El archivo de configuración de vsftpd es /etc/vsftpd.conf. Otros servidores FTP usan archivos similares.

Opciones de configuración de FTP

A continuación se enumeran algunas opciones a tomar en cuenta en /etc/vsftpd.conf (y probablemente en su servidor si usa un servidor diferente):

  • anonymous_enabled: Permite a usuarios anónimos iniciar sesión usando los nombres de usuario "anonymous" o "ftp".
  • anon_mkdir_write_enable: Permite a usuarios anónimos crear directorios (dentro de los directorios primarios editables por todos los usuarios).
  • anon_upload_enable: Permite a usuarios anónimos cargar archivos.
  • anon_world_readable_only: Predeterminadamente activada (en "YES"). No se recomienda modificar esta opción. Permite únicamente archivos de acceso FTP anónimos legibles para todos los usuarios.
  • chroot_list_enable: Especifica un conjunto de usuarios (listados en /etc/vsftpd.chroot-list) "enjaulados en chroot" en su directorio principal al iniciar sesión.
  • ssl_enable: Soporta conexiones encriptadas con SSL.

Para conocer más opciones, consulte las páginas man de su servidor FTP. Por lo general, la ejecución de un servidor FTP se trata simplemente de ajustar un archivo de configuración y ejecutar el servidor dentro de los scripts de inicialización.


Shell seguro (SSH)

Cliente y servidor

Casi todas las máquinas Linux (como casi todos los sistemas operativos) cuentan con un cliente de shell seguro (SSH). La versión más usada es OpenSSH, pero también son frecuentes una variedad de clientes SSH compatibles. Si bien el cliente SSH es esencial para efectuar la conexión con un host, los problemas de seguridad más importantes suelen relacionarse con la configuración correcta del servidor SSH.

Al iniciar una conexión con un servidor, el cliente decide confiar en el servidor de forma activa. El simple hecho de contar con un cliente SSH no permite acceso de ningún tipo al interior de la máquina; por consiguiente, contar con un cliente SSH no significa estar expuesto a vulnerabilidades.

La configuración de un servidor no es una tarea especialmente compleja ya que el daemon de servidor está diseñado para activar y hacer cumplir prácticas de seguridad beneficiosas. De todas formas, debe considerarse que se trata de un servidor que comparte recursos con los clientes cuyas solicitudes decide atender.

El protocolo SSH está disponible en dos versiones, versión 1 y versión 2. En los sistemas más modernos se recomienda usar la versión de protocolo 2, aunque ambos clientes y servidores suelen mantener la compatibilidad con la versión 1 (a menos que esta capacidad se encuentre desactivada en las opciones de configuración) para poder conectarse con los sistemas que sólo admiten la versión 1, que cada vez son menos frecuentes.

Las versiones de protocolo 1 y 2 usan archivos de configuración algo diferentes. En la versión de protocolo 1, el cliente primero crea un par de claves RSA usando ssh-keygen. La clave privada se almacena en $HOME/.ssh/identity y la pública en $HOME/.ssh/identity.pub. Este mismo identity.pub debe agregarse a los archivos $HOME/.ssh/authorized_keys remotos.

Evidentemente, aquí nos enfrentamos al problema del huevo o la gallina: ¿cómo es posible copiar un sistema remoto antes de tener acceso a él? Afortunadamente, SSH también soporta un método de autenticación alternativo que consiste en enviar contraseñas encriptadas en la línea que se evalúan mediante las pruebas usuales de inicio de sesión de sistemas remotos (por ejemplo: la cuenta de usuario debe existir y se debe proporcionar la contraseña correcta).

El protocolo 2 soporta tanto claves RSA como DSA. La autenticación RSA del protocolo 2 no es idéntica a la del protocolo 1, ya que presenta algunas mejoras. En el protocolo 2, las claves privadas se almacenan en $HOME/.ssh/id_rsa y $HOME/.ssh/id_dsa. El protocolo 2 también soporta una serie de algoritmos de confidencialidad e integridad adicionales: AES, 3DES, Blowfish, CAST128, HMAC-MD5, HMAC-SHA1, etc. El servidor puede configurarse en base a los algoritmos y el órden de alternativas deseados.

En las opciones de configuración generales, en lugar de almacenar información de claves, el cliente almacena sus claves en /etc/ssh/ssh_config (o, de estar disponible, en /$HOME/.ssh/config). Las opciones del cliente también pueden configurarse con el switch -o; otro switch muy común es -X o -x, el cual activa o desactiva el reenvío X11. Si se encuentra activado, el puerto X11 se tuneliza a través de SSH para permitir el uso de conexiones X11 encriptadas.

Las herramientas como scp también usan un reenvío de puertos sobre SSH similar. Por ejemplo, en la pantalla local de la máquina local en la que me encuentro trabajando, puede iniciar una aplicación X11 que sólo exista remotamente (en la subred local, en este caso):

Listado 11. Iniciar una aplicación X11 remota
$ which gedit # not on local
system $ ssh -X dqm@192.168.2.2 Password: Linux averatec 2.6.10-5-386 #1 Mon Oct
10 11:15:41 UTC 2005 i686 GNU/Linux No mail. Last login: Thu Feb 23 03:51:15
2006 from 192.168.2.101 dqm@averatec:~$ gedit &

Configuración del servidor

El daemon sshd, específicamente en su versión OpenSSH, permite las comunicaciones encriptadas seguras entre dos hosts no confiables sobre una red no segura. El servidor sshd de base suele activarse durante la inicialización y escucha las conexiones de clientes bifurcando un nuevo daemon para cada conexión de cliente. Los daemons bifurcados administran el intercambio de claves, la encriptación, la autenticación, la ejecución de comandos y el intercambio de datos.

Al igual que con la herramienta de cliente, el servidor sshd acepta una variedad de opciones en la línea de comandos, pero suele estar configurado por el archivo /etc/ssh/sshd_config. También se usan otros archivos de configuración. Por ejemplo, se emplean los controles de acceso /etc/hosts.allow y /etc/hosts.deny. Las claves se almacenan de forma similar a como sucede en el extremo del cliente, en /etc/ssh/ssh_host_key (protocolo 1), /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key; y las claves públicas en /etc/ssh/ssh_host_dsa_key.pub y friends. También, al igual que con el cliente, se usa ssh-keygen para generar las claves en el comienzo. Consulte las páginas man de sshd y ssh-keygen para obtener más información sobre la configuración de archivos y la copia de claves generadas en los archivos correspondientes.

Muchas opciones de configuración se encuentran en /etc/ssh/sshd_config y los valores predeterminados por lo general resultan adecuados (y adecuadamente seguros). Vale la pena destacar algunas opciones:

  • AllowTcpForwarding activa o desactiva el reenvío de puertos (tunelización). Esta opción se encuentra predeterminadamente activada (en "YES").
  • Ciphers controla la lista y el orden de los algoritmos de encriptación a utilizar.
  • AllowUsers y AllowGroups aceptan patrones comodines y permiten establecer cuáles usuarios pueden siquiera intentar autenticarse.
  • DenyGroups y DenyUsers actúan simétricamente, como podría esperarse.
  • PermitRootLogin permite que el SSH del usuario root ingrese a la máquina.
  • Protocol permite especificar si se aceptarán ambas versiones de protocolo (o cuál versión de protocolo se aceptará).
  • TCPKeepAlive es la opción a revisar si está perdiendo conexiones SSH. Si esta opción está activada, envía un mensaje "keepalive" para verificar las conexiones y esto podría causar la desconexión si ocurren errores temporales en la ruta.

Tunelización SSH

OpenSSH le permite crear un tunel para encapsular otro protocolo dentro de un canal SSH encriptado. Esta capacidad se encuentra predeterminadamente activada en el servidor sshd, pero podría haberse desactivado mediante opciones de la línea de comandos o del archivo de configuración. Con esta capacidad activada, los clientes pueden emular fácilmente cualquier puerto/protocolo que deseen usar para una conexión. Por ejemplo, en el Listado 12 se crea un túnel para telnet:

Listado 12. Creación de un túnel para telnet
% ssh -2 -N -f -L
5023:localhost:23 user@foo.example.com % telnet localhost 5023

Por supuesto, este ejemplo no tiene ningún sentido, ya que un shell de comando SSH cumple con la misma función que el Shell telnet. Pero sí tendría sentido crear una conexión POP3, HTTP, SMTP, FTP, X11 u otra conexión de protocolo de manera análoga. El concepto de base consiste en que un puerto de host local específico actúa como si fuera el servicio remoto, logrando que paquetes de comunicación reales se transporten sobre la conexión SSH en forma encriptada.

Las opciones usadas en el ejemplo son las siguientes:

  • -2(usar protocolo 2),
  • -N(sin comandos/solo túnel),
  • -f(SSH en segundo plano) y
  • -L,(describir túnel como "localport:remotehost:remoteport").

También se especifica el servidor (con nombre de usuario).


TCP_wrappers

¿Qué es "TCP_wrappers"?

Lo primero que debe saber de TCP_wrappers es que no debe usarlo y que ya se ha dejado de recibir mantenimiento. Sin embargo, es posible que encuentre que el daemon tcpd de TCP_wrappers se sigue ejecutando en un sistema legado. En una época, ésta solía ser una aplicación útil, pero su funcionalidad ha sido sustituida por iptables y otras herramientas. El propósito general de TCP_wrappers es monitorear y filtrar solicitudes entrantes de SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK y otros servicios de redes.

TCP_wrappers puede configurarse de dos formas distintas. Una es sustituyendo tcpd por otros servidores, proporcionando argumentos para trasladar el control al servidor específico una vez que tcpd haya realizado su correspondiente registro y filtrado. Otro método es no tocar los daemons de red y modificar el archivo de configuración de inetd. Por ejemplo, mediante la entrada

tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot

una solicitud tftp entrante se ejecuta a través del programa contenedor (tcpd) con el nombre de proceso in.tftpd.


Tareas de seguridad

Este objetivo agrupa una gran variedad de tareas importantes para el mantenimiento de la seguridad en la red que me resulta imposible desarrollar de forma exhaustiva en este tutorial. Mi recomendación es que el lector se tome un tiempo para estudiar y practicar los recursos y herramientas enumerados en esta sección.

Algunos sitios Web dedicados al monitoreo de problemas de seguridad y parches son:

  • Security focus news: El sitio Web Security Focus es uno de los mejores para dar a conocer y debatir problemas de seguridad y vulnerabilidades específicas. Este sitio incluye varios newsletters y alertas a los que se puede suscribir, columnas de interés general e informes de errores que admiten búsquedas.
  • The Bugtraq mailing list: Lista de correspondencia de divulgación total administrada por moderadores dedicada al anuncio y debate exhaustivo de vulnerabilidades de la seguridad de computadoras: qué son, cómo explotarlas y cómo arreglarlas.
  • CERT Coordination Center[Centro de coordinación CERT]: El CERT, presentado por la Universidad Carnegie Mellon, ofrece asesoramiento similar al del sitio Security Focus pero con un mayor énfasis en los tutoriales y pautas. Seguir este tipo de sitios es una buena forma de asegurarse de estar al tanto de los incidentes de seguridad que podrían afectar a su sistema operativo, distribución y herramientas o servidores específicos.
  • Computer Incident Advisory Capability[Capacidad de asesoramiento sobre incidentes de computadoras]: Los boletines informativos de la CIAC se distribuyen a la comunidad del Departmento de Energía para informar a los sitios acerca de las vulnerabilidades de seguridad de computadoras y las acciones recomendadas. Además, las notificaciones de asesoramiento de la CIAC cumplen la función de alertar a los sitios acerca de vulnerabilidades graves y urgentes e informar las soluciones que deben aplicarse lo antes posible. Los boletines técnicos de la CIAC abordan problemas técnicos de seguridad y realizan análisis de temas menos urgentes.
  • Información acercade la protección de relés abiertos de correspondencia: Una vulnerabilidad muy común en sistemas con servidores de correspondencia es la incapacidad de proteger eficazmente los sistemas del uso malicioso por parte de los spammers y remitentes fraudulentos. Open Relay Database proporciona tutoriales acerca de herramientas de correo con seguridad especial, herramientas online de prueba de relés abiertos y una base de datos de servidores problemáticos conocidos que pueden emplear los administradores de sitios Web para configurar listas negras.

Algunas herramientas que podría ejecutar para monitorear la seguridad son:

  • Open Source Tripwire: Herramienta de seguridad e integridad de datos para monitorear y alertar acerca de cambios en archivos específicos.
  • scanlogd: Herramienta de detección de exploración de puertos TCP.
  • Snort: Prevención y detección de intrusiones en la red que usa un lenguaje impulsado por reglas; Snort usa métodos de inspección basados en firmas, potocolos y anomalías.

Recursos

Aprender

Obtener los productos y tecnologías

  • Con el software de prueba de IBM, disponible para su descarga directamente desde developerWorks, construya su próximo proyecto de desarrollo en Linux.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=502717
ArticleTitle=Preparación para el examen de LPI: Seguridad de sistemas
publish-date=07292011