jueves, 15 de mayo de 2008

SERVIDOR HTTP, FTP, CORREO, DNS

FTP

El FTP solía ser el protocolo más usado en Internet por el tráfico puro de datos hasta que fue sobrepasado por el HTTP hace unos años (sí, una vez hubo un Internet libre de WWW). El FTP hace una cosa, y lo hace bien, transferir ficheros entre sistemas. El protocolo en sí mismo es inseguro, contraseñas, datos, etc, se transfieren en texto claro y pueden ser esnifados con facilidad, sin embargo la mayoría del uso del ftp es ‘anónimo’, de modo que no es un gran problema. Uno de los principales problemas con que se suelen encontrar los sitios de ftp son los permisos incorrectos en directorios que permiten a la gente utilizar el sitio para distribuir sus propios datos (por lo general material con copyrights). Al igual que con telnet, se debería utilizar una cuenta para hacer ftp que no se utilizara para hacer trabajos administrativos, puesto que la contraseña viaja por la red en texto claro.

En general, los problemas con el ftp incluyen:


Autentificación en texto claro, nombre de usuario y contraseña.
Texto en claro en todos los comandos.
Ataques de adivinación de contraseñas.
Configuración inadecuada del servidor y el consiguiente abuso de servidores.
Todavía existen varios desagradables ataques de Negación de Servicio en algunos servidores de ftp.
Las versiones más antiguas de WU-FTPD y sus derivados tienen ataques de root.

Asegurar FTP no es demasiado difícil, entre los cortafuegos y los TCP_WRAPPERS se puede restringir bastante bien el acceso basado en la dirección IP / hostname. Además, la mayoría de los servidores ftp se ejecutan bajo chroot por defecto para cualquiera con acceso anónimo, o en una cuenta definida como invitado. Con un poco de trabajo, se puede configurar a los usuarios que están haciendo ftp para hacer chroot su directorio personal, o cualquier otra cosa apropiada. También se pueden ejecutar servidores de ftp que cifren los datos (utilizando cosas como SSL/etc.) sin embargo eso significa que tus clientes ftp deben hablar el protocolo de cifrado, y ello no siempre es práctico. También asegúrate de que no se tienen directorios de acceso público en el servidor de ftp que sean a la vez legibles y que se puedan escribir, o si no la gente los explotará para distribuir su propio software (generalmente warez o porno).

Un ejemplo de reglas de filtrado para el cortafuegos:

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 21

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 21

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 21

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 21

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 21

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 21

Un ejemplo de lo mismo utilizando TCP_WRAPPERS:

En /etc/hosts.allow

in.ftpd: 10.0.0.0/255.0.0.0, un.host.fiable

Y en /etc/hosts.deny

in.ftpd: 0.0.0.0/0.0.0.0

Existen diferentes alternativas cifradas a ftp como se mencionó más arriba, SSLeay FTPD y otras utilidades de terceros. puesto que la mayoría de cuentas ftp no se utilizan como cuentas de administración (contraseñas en texto claro, ya has sido advertido), y es de esperar que se ejecuten con chroot, el riesgo de seguridad se minimiza. Ahora que tenemos cubiertas todas las partes de ftp basadas en red, vamos con la forma de asegurar cuentas de usuarios y el entorno.



WU-FTPD

No recomendaría el uso del WU-FTPD, puesto que tiene muchos problemas de seguridad, y bastantes vendedores de Linux no utilizan WU-FTPD en sus propios servidores de ftp. Recomendaría encarecidamente ProFTPD, que está disponible gratuitamente y se desarrolla en la siguiente sección.

Uno de los principales mecanismos de seguridad de WU-FTPD es el uso de chroot. Por ejemplo: por defecto toda la gente haciendo login de forma anónima tiene /home/ftp/ como el directorio raíz. No pueden salir de aquí y, digamos, mirar el contenido de /home/ o /etc/. Lo mismo se aplica a grupos de usuarios y/o individuos, por ejemplo, se podría configurar a todos los usuarios para que fuesen hechos chroot a /home/ cuando hacen el ftp, o en casos extremos de privacidad de usuarios (digamos un servidor de www albergando múltiples dominios) configurar cada usuario con chroot a su propio directorio personal. Esto se hace mediante el uso de /etc/ftpaccess y /etc/passwd (haciendo man ftpaccess se obtienen toda la información). Daré unos cuantos ejemplos de lo que es necesario hacer para llevarlo a cabo, puesto que al principio puede resultar algo confuso. ftpd también verifica /etc/ftpusers y si el usuario que está intentando hacer login aparece listado en ese fichero (como debería estarlo el root) no le dejará acceder vía ftp.

Hacer chroot a usuarios a medida que van haciendo login en el servidor de ftp es bastante simple, pero está pobremente documentado. La comprobación del servidor de ftp de /etc/ftpaccess en busca de "guestgroup"’s, que son simplemente "guestgroup cualquier-grupo-del-sistema" p. ej. "guestgroup usuarios". El nombre de grupo tiene que estar definido en /etc/group y tener añadidos miembros. Es necesario editar la línea de su fichero de contraseñas, de forma que el servidor de ftp sepa dónde volcarlos. Y puesto que ahora están hechos chroot a ese directorio del sistema, no tienen acceso a /lib, etc, así que hay que copiar ciertos ficheros a sus directorios para que cosas como "ls" funcionen correctamente (siempre un toque elegante).

Configurar un usuario (felipefroilan) de forma que pueda entrar por ftp y acabe siendo hecho chroot a su directorio personal (porque sigue amenazando al administrador con llevarle a cazar gamusinos). Además de esto, felipefroilan puede entrar por telnet y cambiar su contraseña, pero nada más, porque sigue intentando ejecutar bots de irc. El sistema en que está utiliza contraseñas con shadow, por eso hay una ‘x’ en el campo de contraseñas de felipefroilan.

Lo primero de todo es que felipefroilan necesita tener una cuenta correctamente configurada en /etc/passwd:

felipefroilan:x:500:Felipe Juan Froilan:/home/felipefroilan/./:/usr/bin/passwd

Lo que significa que el servidor de ftp hará un chroot de felipefroilan y luego le hará un chdir en lo que ahora se conoce como / (/home/felipefroilan para el resto de nosotros). La página del manual de ftpaccess cubre bien todo esto, y por supuesto que /usr/sbin/passwd tiene que estar listado en /etc/shells.

Segundo, para que el servidor de ftp sepa que se le está haciendo chroot, tiene que ser miembro de un grupo (usuariosmalos, genteftp, etc) que venga definido en /etc/group. Y después ese grupo tiene que aparecer listado en /etc/ftpaccess.

Ahora hay que copiar algunas librerías y binarios en la "cárcel" chroot, si no "felipefroilan" no va a poder hacer demasiadas cosas una vez que haya entrado por ftp. Los ficheros necesarios están disponibles como paquete (normalmente llamado "anonftp"), una vez que esté instalado, los ficheros se copiarán a /home/ftp/, te darás cuenta de que hay un /etc/passwd, que sólo se usa para mapear UID’s a nombres de usuarios, si quieres que felipefroilan vea su nombre de usuario y no su UID, añade una línea para él (p. ej., copia esta línea desde el /etc/passwd real por esta otra). Lo mismo se aplica al fichero de grupos.

sin "felipefroilan:*:500:500:::" en /home/felipefroilan/etc/passwd:

drwxr-xr-x 2 500 500 1024 Jul 14 20:46 felipefroilan

y con la línea añadida a /home/felipefroilan/etc/passwd:

drwxr-xr-x 2 felipefroilan 500 1024 Jul 14 20:46 felipefroilan

y con una línea para el grupo de felipefroilan añadida a /home/felipefroilan/etc/group:

drwxr-xr-x 2 felipefroilan felipefroilan 1024 Jul 14 20:46 felipefroilan

Ahora felipefroilan puede hacer un ftp al sistema, subir y descargar ficheros desde el directorio /home/felipefroilan, cambiar él mimo su contraseña y no dañar el sistema, ni descargar el fichero de contraseñas u otro tipo de incordios.

El FTP también es un protocolo bastante especial, pues los clientes se conectan al puerto 21 (por lo general) del servidor de ftp, y luego, en el puerto 20 del servidor de ftp se conecta al cliente, y es sobre esta conexión donde viajan los datos reales. Lo cual significa que el puerto 20 tiene que hacer conexiones externas. Hay que tener esto en cuenta cuando se configure un cortafuegos, ya sea para proteger servidores ftp o clientes utilizando ftp. De igual forma, existe un ftp "pasivo", y generalmente se suele utilizar por visores www/etc, lo cual significa conexiones entrantes al servidor en puertos altos (en lugar de utilizar el 20, se ponen de acuerdo en algún otro). Si se pretende tener un servidor ftp público que SÓLO vaya a servir ftp, y nada más, colócalo preferiblemente fuera de nuestra LAN interna (ver Practical Unix and Internet Security para discusiones del concepto ‘DMZ’). Se puede conseguir WU-FTPD de ftp://ftp.wu-ftpd.org/∞



ProFTPD

ProFTPD es un servidor con licencia GPL que se ejecuta en una variedad de plataformas UNIX. Soporta nuevas características como ftp virtual, configuración por directorio (utilizando ficheros .ftpaccess, similares a los ficheros .htaccess de Apache), soporte para cuentas que han expirado y más. También soporta características bastante útiles como la limitación de descargas y controles de seguridad más férreos que WU-FTPD. Lo recomendaría encarecidamente por encima de otros servidores de FTP para UNIX gratuitos.

El fichero de configuración principal de ProFTPD es /etc/proftpd.conf, tiene un estilo de configuración Apachesca que me gusta mucho. ProFTPD se puede ejecutar desde inetd (y hacer uso de TCP_WRAPPERS) o se puede ejecutar como servidor autónomo. También soporta ficheros de configuración por directorio para limitar el acceso, etc. ProFTPD también soporta ftp virtual (aunque al contrario que con un servidor virtual de www, son necesarias IPs extra) y se puede configurar cada sitio de forma diferente (diferente acceso anónimo, si es que lo hay, y más cosas de entre esas líneas). El fichero general proftpd.conf suele tener una sección que cubre los parámetros globales (inetd o autónomo, número máximo de procesos a ejecutar, como quien se ejecuta, etc.), seguido de un fichero de configuración por defecto, seguido de una configuración específica del sitio (sitios virtuales). En un servidor haciendo hosting virtual probablemente sea una buena idea desactivar "DefaultServer", de modo que cualquier cliente que haga ftp sin ningún objetivo sea denegada, en lugar de volcada dentro del sitio por defecto.

Una configuración de ejemplo de un servidor ProFTPD ejecutándose desde inetd sin acceso anónimo:

ServerName "Instalación por defecto de ProFTPD"

ServerType inetd

DefaultServer on

Port 21

Umask 022

MaxInstances 30

User nobody

Group nobody



AllowOverWrite on



Digamos que, al igual que yo, eres paranoico y quieres controlar el acceso al servidor de ftp mediante direcciones IP, nombres de hosts y nombres de dominio (aunque recomendaría confiar sólo en las IP’s). Esto se puede conseguir mediante reglas del cortafuegos, pero eso acaba ralentizando la máquina (especialmente si se añaden multitud de reglas, como tiende a ocurrir). Se puede utilizar TCP_WRAPPERS , pero no sería posible limitar selectivamente el acceso a sitios virtuales, sitios anónimos, sólo al servidor en sí mismo. O se puede hacer en el fichero proftpd.conf utilizando la directiva "".

El siguiente ejemplo limitará el acceso a 10.1.*.* y 1.2.3.4, a cualquier otra máquina se le denegará el acceso.



Order Allow, Deny

Allow from 10.1., 1.2.3.4

Deny from all



Si se coloca esto dentro de las directivas "" o "", se aplica sólo a ese sitio virtual o configuración anónima, si se coloca en la directiva "" se aplicará a todas las secciones "" y "", y si se coloca en la configuración del servidor (p. ej. con "ServerName" y elementos relacionados) se comportará como lo haría TCP_WRAPPERS, cualquiera desde 10.1.*.* o desde 1.2.3.4 impacta cuando se intenta conectar al puerto 21, al contrario que si simplemente le negase el login si no está en la sección "", "" o "".

Si se quiere añadir más accesos anónimos, tan sólo añadir:



User ftp

Group ftp

RequireValidShell off

UserAlias anonymous ftp

MaxClients 10

DisplayLogin bienvenido.msg

DisplayFirstChdir .message





DenyAll







Esto asignaría el directorio personal de los usuarios "ftp" (suponiendo que la configuración normal de "~ftp" probablemente fuese /home/ftp) como el directorio raíz anónimo, cuando la gente hiciese login anónimo, el ProFTPD se ejecutaría como el usuario "ftp" y el grupo "ftp" (al contrario que si se hiciera login como un usuario normal), y los logins anónimos se limitarían a 10. De igual forma, el fichero /home/ftp/bienvenido.msg se mostraría cuando hiciesen ftp los usuarios anónimos, y cualquier directorio con un fichero .message que contuviera texto, el cual se mostraría al cambiar a tal directorio. El "" se ocupa de /home/ftp/*, y después deniega el acceso de escritura a todos, lo cual quiere decir que nadie puede subir ficheros. Si se quisiera añadir in directorio entrante, simplemente se añadiría lo siguiente después de las directivas "":





AllowAll





DenyAll





Lo cual le permitiría a la gente escribir ficheros en /home/ftp/incoming, pero no leerlos (es decir, descargarlos). Como se puede ver, ProFTPD es muy flexible, lo cual da como resultado mayores requerimientos de potencia que el WU-FTPD, pero definitivamente merece la pena por el control añadido. ProFTPD y su documentación se pueden conseguir en: http://www.protftpd.org/∞

proftpd-ldap

El proftpd-ldap te permite hacer consultas por contraseñas utilizando un directorio LDAP, se puede descargar de: http://horde.net/~jwm/software/proftpd-ldap/∞



NcFTPD

El NcFTPD es un servidor ftp de gran volumen, sin embargo sólo se encuentra disponible para uso personal o educativo. Se puede conseguir en: http://www.ncftpd.com/ncftpd∞.

BSD ftpd

El servidor ftp de BSD (ftpd) también se ha transportado a Linux, de modo que si necesitas ejecutarlo, se puede descargar de: ftp://quatramaran.ens.fr/pub/madore/ftpd-BSD/∞



Muddleftpd

El Muddleftpd is un pequeño servidor de ftp. Se puede conseguir en: http://www.computing.edu.au/~kuiperba/muddleftpd/∞.



Troll ftpd

El Troll ftpd es un servidor ftp extremadamente pequeño y relativamente seguro. No puede ejecutar programas externos, y es bastante fácil de configurar. Se puede conseguir en: http://www.troll.no/freebies/ftpd.html∞.



BetaFTPD

El BetaFTPD es un pequeño servidor ftp de un solo hilo. Se puede conseguir en: http://members.xoom.com/_XOOM/sneeze/betaftpd.html∞.



FTP - SSL

Otro reemplazo de tu ftpd favorito (probablemente WU-FTPD), también disponible como un conjunto de parches para el WU-FTPD. Es altamente apropiado, puesto que la mayoría de los servidores tienen muchos usuarios que necesitan acceso ftp. El tarball está disponible en: ftp://ftp.uni-mainz.de/pub/internet/security/ssl/∞, y como paquetes RPM en ftp://ftp.replay.com/pub/replay/linux/redhat/∞

FTP - SRP

El SRP también se puede utilizar para cifrar la porción nombre de usuario / contraseña de tu sesión ftp, o de la sesión completa. Se puede conseguir en: http://srp.arcot.com/srp/∞

SSH

SSH es un protocolo seguro y un conjunto de herramientas para reemplazar otras más comunes (inseguras). Fue diseñado desde el principio para ofrecer un máximo de seguridad y permitir el acceso remoto a servidores de forma segura. SSH se puede utilizar para asegurar cualquier tráfico basado en red, configurándolo como un pipe (p. ej., vinculándolo a cierto puerto en ambos extremos). Es bastante cutre, pero está bien para utilizar X a través de Internet. Además de esto, los componentes del servidor se ejecutan en la mayoría de sistemas UNIX, y NT, y los componentes del cliente se ejecutan en casi cualquier cosa. Por desgracia SSH ya no es gratis; sin embargo hay un proyecto para crear una implementación gratis del protocolo SSH.

No existen tantos problemas con el SSH per se como existen con telnet, todo el tráfico de la sesión va cifrado y el intercambio de llaves se hace de forma relativamente segura (opcionalmente se pueden precargar las llaves al final, para evitar que sean transmitidas y ser vulnerables a ataques tipo ‘man in the middle’, hombre de por medio. SSH se suele ejecutar como un demonio, y se puede cerrar utilizando el fichero sshd_config. También se puede ejecutar sshd desde inetd, y de tal forma utilizar TCP_WRAPPERS, y por defecto los rpm’s de ftp://ftp.replay.com/∞ tienen la opción de TCP_WRAPPERS compilada. De modo que utilizar "sshd: blahblah" en hosts.allow y hosts.deny te permite restringir con facilidad el acceso a ssh. Por favor, ten en cuenta que las primeras versiones de ssh contienen bugs, y se han hackeado sitios (generalmente con ataques tipo ‘man in the middle’ o problemas de desbordamientos de pila en el código ssh), pero la última versión de ssh tiene en cuenta estos problemas. El principal asunto con ssh es su licencia, sólo es gratis para usos no comerciales, sin embargo se puede descargar el código fuente de una gran variedad de sitios. Si se quiere instalar ssh con facilidad, hay un script llamado "install-ssh" que descargará, compilará e instalará el ssh sin dolor, está disponible en:

ftp://ftp.yellowdoglinux.com/pub/yellowdog/install-ssh/∞

Las reglas del cortafuegos para ssh son bastante parecidas a telnet. Por supuesto que está TCP_WRAPPERS, el problema con TCP_WRAPPERS es que un atacante se conecta al puerto, pero no consigue un demonio, SIN EMBARGO sabe que hay algo en ese puerto, mientras que mediante el cortafuegos, ni siquiera se consigue conexión con el puerto. Lo siguiente es un ejemplo de cómo permitir a la gente ejecutar ssh desde máquinas internas, y ciertas clases C en Internet (por ejemplo la clase C que utiliza tu PSI para su batería de módems de acceso).

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 22

ipfwadm –I –a accept –P tcp –S bateria.módems.psi/24 –D 0.0.0.0/0 22

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 22

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 22

ipchains –A input –p tcp –j ACCEPT –s bateria.módems.psi/24 –d 0.0.0.0/0 22

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 22

O vía TCP_WRAPPERS

hosts.allow:

sshd: 10.0.0.0/255.0.0.0, bateria.módems.psi/255.255.255.0

hosts.deny:

sshd: 0.0.0.0/0.0.0.0

Además de esto, por defecto el ssh trae un fenomenal fichero de configuración, /etc/sshd/sshd_config en la mayoría de las instalaciones. Se puede restringir con facilidad a quién se le permite hacer login, qué hosts, y qué tipo de autentificación les está permitido utilizar. El fichero de configuración por defecto es relativamente seguro, pero lo que sigue es uno más seguro con explicaciones. Ten en cuenta que toda esta información se puede obtener con un "man sshd", la cual es una de las pocas páginas que están bien escritas. Lo que sigue es un fichero sshd-config típico:

Port 22

# se ejecuta en el puerto 22, el standard

ListenAddress 0.0.0.0

# escucha en todos los interfaces, quizás sería prefirible vincularlo

# sólo a un cortafuegos interno, etc.

HostKey /etc/ssh/ssh_host_key

# dónde se encuentra la llave del host

RandomSeed /etc/ssh/ssh_random_seed

# dónde se encuentra la simiente aleatoria

ServerKeyBits 768

# durante cuanto tiempo dura la llave del servidor

LoginGraceTime 300

# cuánto tiempo se tiene para introducir las credenciales

KeyRegenerationInterval 3600

# cada cuánto tiempo se regeneran las llaves del servidor

PermitRootLogin no

# permitir hacer login al root? ni hablar

IgnoreRhosts yes

# ignorar los ficheros .rhosts de los usuarios? Pues claro

StrictModes yes

# para asegurarse de que los usuarios no hacen tonterías

QuietMode no

# Si es sí no hace log de nada. Queremos hacer log de logins/etc.

X11Forwarding no

# ¿reenviar X11? no habría por qué en un servidor

FascistLogging no

# quizás no querramos hacer demasiado log

PrintMotd yes

# mostrar el mensaje del día? Siempre está bien

KeepAlive yes

# se asegura de que las sesiones se desconectan correctamente

SyslogFacility DAEMON

# ¿quién está haciendo el logging?

RhostsAuthentication no

# la autentificación está usando rhosts o /etc/hosts.equiv No está

# en mi mente. Por defecto es sí, de modo que se desactiva.

RSAAuthentication yes

# permitir autentificación RSA pura? Es bastante segura

PasswordAuthentication yes

# permitir a los usuarios que utilicen su login/contraseña habitual?

# Por qué no.

PermitEmptyPasswords no

# permitir cuentas con contraseñas vacias? no

Otras directivas sshd_conf útiles incluyen:

AllowGroups – permitir a grupos explícitamente (/etc/group) hacer login utilizando ssh

DenyGroups – deshabilitar explícitamente hacer login a grupos (/etc/groups)

DenyUsers – bloquear explícitamente a los usuarios el hacer login

AllowHosts – permitir ciertos hosts, al resto se les denegará

DenyHosts – bloquea ciertos hosts, al resto se les permitirá

IdleTimeout time – tiempo en minutos/horas/días/etc, que fuerza un logout haciendo un SIGHUP del proceso.



Software SSH

Fresh Free FiSSH

La mayoría de nosotros todavía nos tenemos que sentar frente a estaciones windows, y los clientes ssh para windows son bastante difíciles de encontrar. Fresh Free FiSSH es un cliente ssh gratuito para Windows 95/NT 4.0. Aunque todavía no está completado, recomendaría echarle un vistazo si eres como yo y tienes muchas estaciones Windows. La URL es: http://www.massconfusion.com/ssh/∞



Tera Term

Tera Term es un cliente gratuito para Windows y tiene una DLL añadida para soportar ssh. Tera Term está disponible en: http://hp.vector.co.jp/authors/VA002416/teraterm.html∞. La DLL añadida para soporte SSH se encuentra disponible en: http://www.zip.com.au/~roca/ttssh.html∞

putty



putty es un cliente SSH para Windows, bastante bueno, y completamente gratis, además de pequeño (184k en la actualidad). Se puede descargar de: ftp://rak.isternet.sk/mnt/rhcd/misc/putty/∞



mindterm

mindterm es un cliente gratuito de ssh en java, se puede conseguir en: http://www.mindbright.se/mindterm/∞



LSH

LSH es una implementación gratuita del protocolo SSH (ambos cliente y servidor), LSH trae licencia GNU y se está empezando a parecer a la alternativa (comercialmente hablando) a SSH (que ya no es gratis). Se puede descargar de: http://www.net.lut.ac.uk/psst/∞, ten en cuenta que está bajo desarrollo.



Secure CRT

Un Telnet/Cliente SSH comercial de software Vandyke. Se puede descargar / comprar en: http://www.vandyke.com/∞

Fsh

Fsh significa "Fast remote command execution", "Ejecución remota rápida de comandos", y en concepto es similar al rsh/rcp. Evita el gasto de tener que estar constantemente creando sesiones cifradas, mediante el uso de un túnel cifrado utilizando SSH o LSH, y ejecutando todos los comandos sobre él. Se puede conseguir en: http://www.lysator.liu.se/fsh/∞

SSH Win32 ports

Existen ports del SSH a Win32 disponibles en: http://guardian.htu.tuwien.ac.at/therapy/ssh/--∞-

Telnet

Telnet fue uno de los primeros servicios de lo que ahora se conoce como Internet, permitiéndote hacer login interactivo en una máquina remota, lanzar comandos y ver sus resultados. Todavía sigue siendo la herramienta primaria por defecto para administración remota en la mayoría de los entornos, y cuenta con soporte casi universal (incluso el NT tiene un demonio y un cliente de telnet). También es uno de los protocolos más inseguros, susceptible al sniffing, hijacking, etc. Si se tienen clientes utilizando telnet para llegar hasta el servidor, se debería hacer un chroot de sus cuentas si esto es posible, de igual forma que restringir el telnet a los hosts que se utilicen mediante TCP_WRAPPERS. La mejor solución para asegurar el telnet es deshabilitarlo y utilizar telnet con SSL o el ssh.

Los problemas con telnet incluyen:


Autentificación en texto claro, nombre de usuario y contraseña.
Texto en claro de todos los comandos.
Ataques de adivinación de contraseñas (como mínimo acabarán en los ficheros de log)

La mejor solución es desactivar el telnet y utilizar ssh. Sin embargo esto no es práctico en todas las situaciones. Si es necesario utilizar telnet, sugeriría encarecidamente filtrarlo mediante un cortafuegos, tener reglas para permitir a los hosts/redes acceso a puerto 23, y después tener una regla general denegando acceso al puerto 23, al igual que utilizar TCP_WRAPPERS (lo cual es más eficiente, puesto que el sistema sólo comprueba cada conexión de telnet y no cada paquete contra las reglas del cortafuegos) sin embargo utilizar TCP_WRAPPERS le permitirá a la gente dar por hecho que se está ejecutando telnet, les permite conectar, se evalúa la conexión, y después se cierra si no se está listado como permitido el acceso. Un ejemplo de reglas del cortafuegos:

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 23

ipfwadm –I –a accept –P tcp –S un.host.fiable –d 0.0.0.0/0 23

ipchains –A input –p all –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 23

Un ejemplo de lo mismo utilizando TCP_WRAPPERS:

En /etc/hosts.allow

in.telnetd: 10.0.0.0/255.0.0.0, un.host.fiable

Y en /etc/hosts.deny

in.telnetd: ALL

Existen varias alternativas cifradas al telnet, como ya se mencionó más arriba, ssh, SSLeay Telnet y otras utilidades de terceros, a mi personalmente me parece que la "mejor" alternativa si te vas a tomar la molestia de cambiar el telnet por algo mejor es utilizar ssh.

Para asegurar las cuentas de los usuarios con respecto a telnet, se pueden hacer varias cosas. La primera sería no permitir al root hacer login vía telnet, lo cual se controla mediante el /etc/securetty y por defecto en la mayoría de las distribuciones el root tiene restringido el acceso a la consola (una buena cosa). Para que un usuario haga login con éxito, su shell tiene que ser válido (lo cual viene determinado por la lista de shells de /etc/shells), de modo que configurar cuentas de usuario a las que se les permita hacer login es simplemente cuestión de configurar su shell a alguno de los listados en /etc/shells. Es hora de algunos ejemplos prácticos de lo que se puede conseguir configurando el shell del usuario para otro tipo de cosas además de para hacer shell.

Para un PSI que quiere permitir a sus clientes cambiar sus contraseñas con facilidad, pero no permitirles acceso al sistema (mi PSI utiliza Ultrasparcs y por alguna razón se niega a distribuir cuentas de usuario, me pregunto porqué).

en /etc/shells se lista:

/usr/bin/passwd

Y se cambia el shell de los usuarios por /usr/bin/passwd, de modo que se tiene algo así:

nombreusuario:x:1000:1000::/home/nombreusuario:/usr/bin/passwd

et voilá. El usuario hace un telnet al servidor, se le pregunta su nombre de usuario y contraseña, y después se le pide cambiar la contraseña. Si se hace correctamente, passwd termina y se les desconecta. Si no tienen éxito, passwd sale y se les desconecta. Lo que sigue es una transcripción de tal configuración cuando un usuario hace telnet:

Trying 1.2.3.4...

Connected to localhost

Escape character is ‘^]’.

Red Hat Linux release 5.2 (Apollo)

Kernel 2.2.5 on an i586

login: tester

Password:

Changing password for tester

(current) UNIX password:

New UNIX password:

Retype new UNIX password:

passwd: all authentication tokens updated successfully

Connection closed by foreign host.

Telnet también muestra un banner por defecto cuando se conecta alguien. El banner suele contener información del sistema, como el nombre, el SO, la versión y a veces otro tipo de información detallada, como la versión del kernel. Antaño esto era útil cuando se trabajaba en múltiples SO’s, sin embargo en la Internet hostil de hoy suele ser más perjudicial que útil. Telnet muestra los contenidos del fichero /etc/issue.net (generalmente es idéntico a /etc/issue el cual se muestra en los terminales, etc.), este fichero se suele volver a crear al arrancar, en la mayoría de las distribuciones de Linux, desde el fichero de arranque rc.local. Simplemente edita el fichero rc.local, ya sea modificando lo que pone en /etc/issue y /etc/issue.net, o comentando las líneas que crean esos ficheros, y después editando los ficheros con información estática.

Los contenidos de un fichero rc.local típico pertenecientes a /etc/issue y /etc/issue.net:

# This will overwrite /etc/issue at every boot. So make any changes

# you want to make to /etc/issue here or you will lose them when you

# reboot.

echo "" > /etc/issue

echo "$R" >> /etc/issue

echo "Kernel $(uname –r) on $a $(uname –m)" >> /etc/issue

cp –f /etc/issue /etc/issue.net

echo >> /etc/issue

simplemente comenta las líneas o elimina los comandos uname. Si es absolutamente necesario habilitar el telnet para hacer logins de usuarios, asegúrate de mostrar una advertencia:

Este sistema es exclusivamente para usos autorizados.

Los infractores serán perseguidos.

o algo similar. Legalmente se está en una posición más fuerte si alguien revienta el sistema o abusa de cualquier otra forma de tu demonio telnet.

Cortafuegos

Un cortafuegos consiste en filtrar el tráfico TCP-IP, generalmente en el punto donde la red se conecta a otra (p. ej. a Internet, a una LAN de clientes, etc), que puede ser no fiable (en el caso de Internet) o quizás incluso fiable (otro piso de tu edificio). Al igual que los cortafuegos de los grandes edificios, un cortafuegos de red puede evitar e incluso bloquear la extensión del ataque si un segmento se ve comprometido con éxito, al igual que su homónimo cortafuegos puede evitar que la red se siga viendo comprometida.

Linux ha tenido capacidad de cortafuegos desde hace ya un tiempo, en forma de ipfwadm, que era un filtro a nivel de paquetes muy sencillo. Con la llegada del kernel 2.1, se ha visto reemplazado por ipchains, que es un poco más sofisticado. Este a su vez se verá reemplazado en el propuesto kernel 2.4, con un filtrado de paquetes todavía más avanzado, que es más independiente. Sin embargo, ambos todavía siguen siendo filtros de paquetes, y no permiten características más avanzadas como la inspección de estados o algunos tipos de conexiones proxy. Sin embargo Linux soporta IPMASQ, una forma de NAT (Traducción de Direcciones de Red, Network Address Translation). El IPMASQ permite enganchar una red de ordenadores a Internet, pero haciendo un proxy de sus conexiones a nivel de IP. De tal forma que todo el tráfico parezca provenir y dirigirse a una máquina (la máquina Linux con IPMASQ), lo cual proporciona un alto grado de protección a la red interna. Como plus añadido, los clientes de la red interna NO necesitan configurar su proxy; mientas el servidor IPMASQ del Linux esté bien configurado y los clientes lo utilicen como su puerta de enlace por defecto, todo irá bien.

Ambos ipchains e ipfwadm proporcionan las siguientes funcionalidades:


bloqueo / permiso del paso de datos basado en IP/puerto/interface origen/destino
enmascaramiento de conexiones, basado en IP/puerto/interface origen/destino

Además, ipchains soporta:


redireccionamiento de puertos
creación de cadenas, para reglas y condiciones más complejas, más fácil de mantener
routing de calidad de servicio (QOS, Quality of Service), útil en conexiones de baja velocidad o saturadas
especificación de IP/puerto/interface además de especificación inversa (utilizando el !)

El HOWTO del cortafuegos y las páginas "man " (ipchains o ipfwadm) se ocupan en gran detalle de la mecánica para la configuración de las reglas, pero en realidad no se ocupan de la estrategia para hacer un filtrado de forma segura. La primera elección que se debe hacer es si se va a seguir una política de denegación o de permisión por defecto, seguido de qué servicios y hosts se quiere permitir y bloquear.

Cuando se vaya a decidir la política, se debería escoger aquella que deniego todo por defecto, a menos que esté específicamente permitido (de forma que si existe un fallo, con suerte se vea minimizado vía política por defecto) o una política que permita todo y bloquee ciertos servicios/hosts. Generalmente suelo utilizar una política de denegación por defecto, pues de esta forma puedo arreglar errores y cambios de forma más segura que una política que permita el flujo de datos por defecto.

Pongamos por caso, se tiene un servidor asegurado vía filtrado con cortafuegos, ejecutando Apache, se instala WU-FTPD para uso interno (de modo que la gente pueda subir ficheros) a las 3 de la mañana, y se te olvida cambiar las reglas del cortafuegos. Si se ha escogido una política permisiva por defecto, cualquiera puede acceder al servidor ftp desde Internet, y además, cometiste el error de instalar una versión antigua que permitía a cualquiera comprometer la máquina. Si por otra parte, se sigue una política de denegación por defecto, no hubiesen accedido al servidor de ftp, ni lo hubiesen hecho tus usuarios, pero te darías cuenta más rápidamente. Los usuarios enfadados son algo más sencillo de tratar que una red que haya sido comprometida.

En esta sección, he decidido no tratar específicamente las reglas de filtrado del cortafuegos, daré ejemplos para cada servicio de red, puesto que para filtrar adecuadamente un protocolo primero hay que entender cómo se comporta. Por ejemplo, existe una gran diferencia entre filtrar el www y el ftp en cuanto a accesos internos y externos. Algunas reglas/conceptos generales:



IPFWADM

El Ipfwadm es un sólido paquete de filtrado para Linux, aunque carece de muchas características disponibles en Ipchains. Ipfwadm sólo soporta 3 objetivos para cada paquete: aceptar, denegar o rechazar, mientras que las reglas del ipchains se pueden dirigir a 6 objetivos, o a un objetivo definido por el usuario. En realidad, el Ipfwadm sólo es apropiado para un cortafuegos sencillo a nivel IP, enmascaramiento de IP y si se tiene previsto utilizar FreeS/WAN. Las opciones básicas son: especificar una dirección (dentro, fuera, o ambas, útil con el flag de interface), reglas de entrada, reglas de salida, reglas de redireccionamiento (pongamos que se tienen múltiples interfaces, también se ocupa de las reglas de enmascaramiento) y reglas de enmascaramiento que controlan el comportamiento del enmascaramiento (timeouts, etc). Se pueden insertar, añadir y borrar reglas, configurar políticas por defecto y listar todas las reglas. Aparte de eso es muy parecido a ipchains, con pequeñas variaciones. Lo que viene a continuación es un script apropiado para un servidor que está haciendo de bridge entre 2 redes (10.0.0.x en eth0, 10.0.0.1 y 192.168.0.x en eth1, 192.168.0.1) ejecutando un servidor de correo.

#!/bin/bash

#

# Primero limpiar todas las reglas

#

ipfwadm -f -I

ipfwadm -f -O

ipfwadm -f -F

#

# Permitir el redireccionamiento entre las dos redes y si no es entre # ellas, denegarlo

#

ipfwadm -F -a accept -P all -S 10.0.0.0/24 -i eth0 -D 192.168.0.0/24

ipfwadm -F -a accept -P all -S 192.168.0.0/24 -i eth1 -D 10.0.0.0/24

ipfwadm -F -p deny

#

# Y por supuesto hay que dejar que entren los paquetes

#

ipfwadm -I -a accept -P tcp -S 10.0.0.0/24 -i eth0 -D 192.168.0.0/24

ipfwadm -I -a accept -P tcp -S 192.168.0.0/24 -i eth1 -D 10.0.0.0/24

#

# Dejarles acceder al servidor de correo pero a nada más

#

ipfwadm -I -a accept -P tcp -S 10.0.0.0/24 -i eth0 -D 10.0.0.1 25

ipfwadm -I -a accept -P tcp -S 192.168.0.0/24 -i eth0 -D 192.168.0.1 25

ipfwadm -I -p deny

Ahora el FreeS/WAN soporta la serie 2.2.x del kernel, nunca se debería escoger ipfwadm sobre ipchains. Ipchains ofrece un grado de control mucho más afinado y es mucho más flexible que ipfwadm.



IPCHAINS

El ipchains contiene algunas características nuevas comparado con ipfwadm; se pueden crear cadenas de reglas (de aquí el nombre) y enlazarlas juntas, haciendo más sencilla la administración de cortafuegos. El ipchains soporta más objetivos que ipfwadm; se puede apuntar una regla a: ACCEPT, DENY, REJECT, MASQ, REDIRECT o RETURN o a una cadena definida por el usuario. Como tal es bastante potente, se podría, por ejemplo, redireccionar todos los paquetes destinados al puerto 80 (tráfico www) de mi puerta de enlace para que se redirigiesen al puerto local 3128, el servidor proxy de Squid. También se puede utilizar esto junto con el routing de calidad de servicio, el ejemplo dado en la documentación de ipfwadm es priorizar el tráfico sobre un enlace PPP, se le puede dar una prioridad más alta al tráfico de telnet que al de, pongamos, ftp, reduciendo los problemas de latencia causados por un enlace saturado. Por lo general, creo un fichero /etc/rc.d/init.d/ipchains-sh (o en cualquier otro lugar apropiado) y lo llamo inmediatamente después de que arranca la red, lo cual deja un tiempo pequeño durante el cual el servidor es vulnerable, pero mínimamente, pues todavía no se están ejecutando demonios de red.

El siguiente script es apropiado para una puerta de enlace ejecutándose con 2 interfaces, que es por lo que he utilizado el objetivo DENY en lugar de REJECT, de modo que se descarte el paquete y no se responda de ninguna manera, lo cual ralentiza los escaneos de red (puesto que esperan el timeout en lugar de recibir una respuesta) y revela menos información. También desaconsejaría guardar logs de los datos, a menos que se disponga de la suficiente cantidad de espacio en disco duro, puesto que cada paquete que se envía (varios bytes) se utilizan muchos bytes de disco duro para crear la entrada del log, siendo fácil saturar el syslog y/o el disco duro en una conexión rápida. La página del ipchains se encuentra en: http://www.rustcorp.com/linux/ipchains/∞

#!/bin/bash

#

# Este script configura las reglas apropiadas de un cortafuegos para un

# servidor con 2 interfaces ejecutándose como puerta de enlace.

#

# Si se planea utilizarlo, es necesario editar este script.

#

# Se supone que las máquinas internas hacen todas una llamada a la puerta

# de enlace, de modo que las reglas no bloquean el tráfico interno.

#

# Un par de variables

#

# ETH0IP es la dirección IP de ETH0 (el interfaz externo)

# ETH0NET es la red

# ETH0NETMASK es la máscara de red

# HOSTFIABLE1 es un host fiable (para administración de web/ssh)

# HOSTFIABLE2 es un host fiable (para administración de web/ssh)

# ETH1IP es la dirección IP de ETH1 (el interfaz interno)

# ETH1NET es la red

# ETH1NETMASK es la máscara de red

#

ETH0IP=1.1.1.1

ETH0NET=1.1.1.0

ETH0NETMASK=24

HOSTFIABLE1=1.5.1.1

HOSTFIABLE2=1.5.1.2

ETH1IP=10.0.0.1

ETH1NET=10.0.0.0

ETH1NETMASK=24

#

PATH=/sbin

# LIMPIAR TODAS LAS REGLAS

ipchains -F input

ipchains -F output

ipchains -F forward

# ANTI-SPOOFING

ipchains -A input -p all -j DENY -s 10.0.0.0/8 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s 127.0.0.0/8 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s 192.168.0.0/16 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s 172.16.0.0/16 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s $ETH0IP -i eth0 -d 0.0.0.0/0

# PRIMERO ICMP

ipchains -A input -p icmp -j ACCEPT -s $ETH0NET/$ETH0NETMASK -i eth0 -d 0.0.0.0/0

ipchains -A input -p icmp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0

# SSH

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE1 -i eth0 -d 0.0.0.0/0 22

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE2 -i eth0 -d 0.0.0.0/0 22

# BLOQUEO 1:1023

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023

# BLOQUEO DE OTRAS COSAS

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1109

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1524

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1600

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2003

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2049

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2105

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3001

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3001

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3128:3130

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3128:3130

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3306

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3306

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 4444

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6000:6100

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6000:6100

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6667

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 7000

# ADMINISTRACIÓN DE WEB

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE1 -i eth0 -d 0.0.0.0/0 10000

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE2 -i eth0 -d 0.0.0.0/0 10000

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 10000

# REGLAS DE REDIRECCIONAMIENTO

ipchains -P forward DENY

ipchains -A forward -p all -j MASQ -s $ETH1NET/$ETH1NETMASK -d 0.0.0.0/0



NETFILTER

El NETFILTER es la siguiente generación de filtrado de paquetes para Linux. Debería de hacer otro tipo de cosas más fácilmente, como cortafuegos, IPSec, cualquier cosa que tenga que ver con la gestión de paquetes. El HOWTO se encuentra disponible en: http://netfilter.kernelnotes.org/∞

IPF

El IPF es un paquete de cortafuegos alternativo, disponible para Linux (y la mayoría de sistemas operativos). Se puede conseguir en: http://cheops.anu.edu.au/∞




SINUS Firewall

El SINUS Firewall es un cortafuegos alternativo para Linux (kernel 2.0.x and 2.2.x). Se puede conseguir en: http://www.sinusfirewall.org/∞.




Phoenix Adaptive Firewall

Estoy en proceso de evaluar el producto, sin embargo parece bastante prometedor. Reemplaza ipchains completamente y añade un montón de inteligencia al proceso de filtrado. Sin embargo es un producto comercial (sobre los 3000$ US), y es el primer cortafuegos para Linux en estar certificado por la ICSA. Está disponible en: http://www.progressive-systems.com/products/phoenix/∞



Creación de Reglas

ipfwadm2ipchains

Un simple script que convierte las reglas de ipfwadm a ipchains, haciendo más fácil la migración. El script se encuentra disponible en la siguiente dirección: http://users.dhp.com/~whisper/ipfwadm2ipchains/∞



mason

Mason es un generador automático de reglas para ipfwadm e ipchains. Se carga y monitoriza el flujo de paquetes a través de la máquina, y después, basándose en eso crea un conjunto de reglas para permitir ese tipo de actividad (p. ej. si se hace un ftp al servidor desde un sitio remoto, permitirá ese tipo de acceso en las reglas que crea). Es una buena herramienta para administradores de cortafuegos novatos, disponible en: http://users.dhp.com/~whisper/mason/∞



firewall.sh

Un script basado en diálogo que te conduce a través de la creación de reglas de filtrado, bastante bien hecho y está orientado a nuevos usuarios, disponible en: http://devplanet.fastethernet.net/Utilities/∞



Mklinuxfw

Mklinuxfw es una herramienta perl dirigida a proporcionar una variedad de interfaces (CGI, KDE, línea de comandos, etc.) para la creación de reglas de cortafuegos. Actualmente soporta interfaz CGI y está en progreso el GTK. Se puede descargar de: http://www.madhouse.org.uk/~red/framepage.phtml?/mklinuxfw/index.html∞



kfirewall

kfirewall es una aplicación basada en GUI para la creación de reglas ipfwadm o ipchains. Se puede conseguir en: http://megaman.ypsilonia.net/kfirewall/∞

fwconfig

fwconfig es una herramienta interesante para configurar ipfwadm e ipchains, basada en www. Se puede descargar desde: http://www.mindstorm.com/~sparlin/fwconfig.shtml∞

xipfwadm

xipfwadm es una aplicación Tcl/Tk para X que simplifica la creación de reglas ipfwadm. Se puede conseguir en: http://www.x25.org/xipfwadm.html∞

Firewall Manager

Firewall Manager es una aplicación Tcl/Tk orientada a ser ejecutada desde X-Window que proporciona un GUI para gestión de cortafuegos. Se puede descargar desde: http://www.tectrip.net/arg/∞




Linux Firewall Tools

Un sitio interesante, tiene un cgi online para crear scripts de cortafuegos, aunque a mi no me funcionó (muy lento). Se puede ver en: http://www.linux-firewall-tools.com/∞.

FCT - Firewall Configuration Tool

Una de las herramientas de configuración online mediante cgi más avanzadas. Se puede probar en http://www.fen.baynet.de/~ft114/FCT/index.htm∞.

DNi

DNi es un cgi online que te ayuda a crear reglas de cortafuegos para ipfwadm. Se puede probar en: http://members.tripod.com/~robel/dni/∞.

Software de Proxy

Existe una variedad de paquetes de software de proxy para Linux. Algunos son a nivel de aplicación (como SQUID) y otros son a nivel de sesión (como SOCKS)

SQUID∞

SQUID es un proxy a nivel de aplicación para HTTP, HTTPS y FTP. También puede ejecutar peticiones DNS bastate más rápido de lo que puede hacerlo la mayoría del software cliente. SQUID es ideal para acelerar el acceso a www, y para controlar el acceso a sitios web (utilizando paquetes como squidGuard)

Rutado

routed

routed es uno de los paquetes de rutado standard disponibles para Linux. Soporta RIP (uno de los protocolos de rutado más viejos todavía en servicio), y ya está. El RIP es muy simple, los routers simplemente hacen un broadcast de sus tablas de rutado a los routers vecinos, lo cual da como resultado (en teoría) una tabla completa de rutado que tiene entradas para cada destino en Internet. Este método es fundamentalmente inseguro, y muy ineficiente más allá de pequeñas redes seguras (en cuyo caso probablemente no sea necesario). Asegurarlo no es posible, se puede configurar un cortafuegos en los puertos 520 y 521, que son los que utiliza RIP para transferir, sin embargo puede dar como resultado rutas a través de las cuales preferirías no atravesar, y los atacantes pueden seguir falsificando las rutas. Ejecutar este servicio es una idea muy mala.



gated

gated es un software de rutado más avanzado que routed. Soporta versiones de RIP 1 y 2, DCN HELLO, OSPF versión 2, EGP versión 2, BGP versiones 2 a 4. Actualmente el protocolo de rutado más popular parece ser el BGP (Border Gateway Protocol), ganando en popularidad el OSPF (OSPF tiene seguridad incorporada, es muy eficiente y bastante más complicado).



zebra

zebra tiene bastantes más características que gated, y ostenta una bonita línea de interfaz de comandos al estilo de Cisco. Se ejecuta como un demonio, multi-hilo para el rendimiento, cada protocolo (RIP, OSPF, etc.) tiene su propia configuración, y se pueden ejecutar múltiples protocolos a la vez (aunque podría originar confusiones/problemas). Existe un puerto de configuración maestro, y un puerto para cada protocolo:

zebrasrv 2600/tcp #zebra service

zebra 2601/tcp #zebra vty

ripd 2602/tcp #RIPd vty

ripngd 2603/tcp #RIPngd vty

ospfd 2604/tcp #OSPFd vty

bgpd 2605/tcp #BGPd vty

ospf6d 2606/tcp #OSPF6d vty

Recomendaría filtrar estos puertos con el cortafuegos. El acceso se controla vía contraseña de login, y el acceso a las funciones de comandos solicita otra contraseña (utilizando la misma sintáxis que en Cisco, "enable"). Se puede descargar de: http://www.zebra.org

Cifrado de servicios / datos

Cifrado de servicios de red

Prácticamente todo el tráfico de red viaja sin cifrar y puede ser leído con facilidad por un atacante. Si alguien revienta una máquina del lado de Internet e instala un sniffer de contraseñas (en realidad no es más que el sniffer de paquetes básico con un filtro), la red entera puede verse comprometida en cuestión de horas. Un PSI que permanecerá en el anonimato, colocó máquinas de clientes en la misma LAN, utilizando un hub ethernet normal y corriente, lo cual quiere decir que todas las máquinas podían ver el tráfico entre sí (usuarios recogiendo su correo vía pop, sesiones de telnet, etc.). Esta es una de las razones por las cuales es una buena idea el cifrado del tráfico de datos.

Existen o se están desarrollando varios mecanismos para cifrar el tráfico de red, en diferentes niveles de la pila de red. Algunos esquemas sólo cifran los datos que se envían (como el correo cifrado con PGP), algunos cifran la sesión (SSL), y algunos cifran la carga de datos de los paquetes (IPSec y otros VPN’s). A la larga, la mejor solución será el IPSec (en mi opinión), puesto que no requiere modificar las aplicaciones, y proporciona un nivel de seguridad entre ordenadores bastante elevado. Actualmente no existen soluciones de cifrado ampliamente utilizadas, en parte porque Microsoft no soporta muchas, lo cual es un serio obstáculo para cualquier solución masiva. Para ser justos, Microsoft tiene soporte para IPSec en fase beta, pero todavía no está preparado, y quedará restringido al mercado Norte Americano debido a la ley de los EE.UU. En la actualidad, el mejor esquema disponible es el SSL, Secure Sockets Layer, propuesto originalmente por Netscape. El SSL cifra los datos a nivel de sesión, de modo que si tu aplicación soporta SSL y el servidor soporta SSL, se está de suerte. Hoy en día, la mayoría de visores www, algunos lectores de news/correo, y unos pocos clientes de ftp y de telnet soportan SSL. En cuanto a servidores Linux, la mayoría de los servicios se pueden "SSLificar". Sin embargo el SSL necesita clientes con capacidad SSL, algo que no se podrá conseguir que soporte la mayoría de la gente. Esto significa que por lo general, los servicios "SSLificados" están restringidos dentro de una organización. Las librerías SSL se encuentran disponibles en http://www.openssl.org/∞.



SSL

HTTP – SSL

El servidor www más habitual, Apache, tiene bastante buen soporte SSL, el cual se puede descargar gratuitamente fuera de los EE.UU. (las patentes de los EE.UU. sobre RSA/etc significan tener que pagar derechos dentro de los EE.UU, de modo que el software gratuito es ilegal) desde http://www.Apache-ssl.org/∞. Hay muchos servidores comerciales de www que soportan SSL, la mayoría de los cuales están basados en Apache, como el Servidor Seguro de Red Hat, Stronghold, etc.



Telnet – SSL

Para reemplazar al telnet, SSLtelnet y MZtelnet proporcionan un nivel de seguridad mucho más alto que el telnet original, aunque el SSLtelnet y el MZtelnet no son tan flexibles como el SSH, son perfectamente libres ( es decir, con licencia GNU) lo cual el SSL no lo es. Los paquetes cliente y servidor se encuentran disponibles como tarballs en: ftp://ftp.uni-mainz.de/pub/internet/security/ssl/∞, y como paquetes RPM en: ftp://ftp.replay.com/pub/replay/linux/Red Hat/∞.



FTP – SSL

También existe un reemplazo para nuestro ftpd favorito (probablemente el WU-FTPD), también disponible como un conjunto de parches al WU-FTPD. Es altamente apropiado, pues la mayoría de los servidores tienen muchos usuarios que necesitan acceso ftp. El tarball se encuentra en: ftp://ftp.uni-mainz.de/pub/internet/security/ssl/∞, y los paquetes RPM están en: ftp://ftp.replay.com/pub/replay/linux/Red Hat/∞.



Soluciones para Redes Privadas Virtuales

IPSec

El IPSec tiene su propia sección. Creo que es el futuro de la tecnología VPN (hoy en día es el standard más soportado, y una parte integral del IPv6).

PPTP (Point to Point Tunneling Protocol)

El PPTP es un protocolo propietario creado por Microsoft para soluciones VPN. Hasta la fecha se ha demostrado que contiene numerosos fallos serios. Sin embargo, si se necesita integrar Linux en un entorno PPTP, no está todo perdido, en http://www.moretonbay.com/vpn/pptp.html∞ se encontrará una implementación de PPTP para Linux.



CIPE (Crypto IP Encapsulation)

CIPE es un esquema gratuito de cifrado a nivel IP, orientado al uso entre routers. Es adecuado para hacer "bridging" de redes con seguridad sobre redes inseguras (como Internet). El sitio oficial está en: http://sites.inka.de/~W1011/devel/cipe.html∞. Sin embargo recomendaría el FreeS/WAN como una mejor solución a largo plazo.



ECLiPt Secure Tunnel (actualmente en fase beta)

Otra solución con licencia GNU para VPN’s bajo Linux. Actualmente en fase beta (y no está recomendado para uso masivo) aunque he pensado que lo mencionaría, puesto que parece ser un esfuerzo serio. La página oficial se encuentra en: http://eclipt.uni-klu.ac.at/projects/est/∞. De nuevo, recomendaría FreeS/WAN como una mejor solución a largo plazo.



Stunnel

Stunnel es una solución basada en SSL para asegurar servicios de red. Tiene una porción servidor que se ejecuta en el servidor UNIX, y una parte cliente que se ejecuta en UNIX o en Windows. http://mike.daewoo.com.pl/computer/stunnel/∞



Cifrado de datos

También se encuentran disponibles diferentes programas para cifrar tus datos, algunos a nivel de fichero (PGP, GnuPG, etc.) y algunos a nivel de unidad de disco (Cryptographic FileSystem, Sistema de Ficheros Criptográfico, por ejemplo). Estos sistemas son muy adecuados para el almacenamiento de datos seguros, y en cierta medida para la transmisión segura de datos. Sin embargo se necesita el software adecuado en ambos extremos, versiones compatibles, y de alguna forma tendrá que llevarse a cabo un intercambio de llaves públicas, lo cual, por desgracia es una onerosa tarea para la mayoría de las personas. Además de esto, no existe una forma sencilla de confiar en la llave pública de una persona a menos que se reciba directamente de esa persona (como por ejemplo en una fiesta de firmado de llaves), o a menos que esté firmada por alguien en quien se confía (¿pero cómo se consigue de forma segura la llave del firmante?). Sistemas para cifrar unidades, como el CFS (Cryptographic FileSystem, Sistema de Ficheros Criptográfico) suelen ser fácil de implementar, y sólo necesitan que el usuario proporcione una contraseña o llave, o alguna forma de acceder a sus ficheros.



PGP (Pretty Good Privacy, Privacidad Bastante Buena)

El abuelito del cifrado público, es con mucho uno de los programas más populares, soportado por Unix, Windows y Macintosh. Por desgracia ahora se ha comercializado, lo cual ha dado como resultado una pérdida de calidad para los usuarios. Personalmente, creo que cualquier software utilizado para cifrar o asegurar datos de cualquier otra forma, DEBE ser código libre, o si no cómo se va a asegurar que es seguro. El PGP ahora lo vende Network Associates y no puedo recomendarlo de buena fe como un mecanismo de seguridad para el almacenamiento y transmisión de ficheros. El PGP se encuentra disponible para descargar de: ftp://ftp.replay.com/∞



GnuPG (Gnu Privacy Guard, Guardián de Privacidad Gnu)

La alternativa al PGP, GnuPG (GPG) es un reemplazo directo completamente de código abierto y con licencia GNU (como si no se adivinase por el nombre). Esta herramienta está disponible en: http://www.gnupg.org/∞, como código fuente o en binarios precompilados para windows y RPM’s.



pgp4pine

El pgp4pine es un shell PGP para pine, que facilita el uso de PGP/GnuPG con el pine. La firma / cifrado, etc. también se han hecho más sencillas. Se puede conseguir en: http://members.home.com/cdwiegand/pgp4pine/∞



HardEncrypt

HardEncrypt es un generador pad de un sólo uso y un conjunto de herramientas para utilizarlo. En teoría, los pads de un sólo uso son una forma de cifrado casi irrompible. Utilizando un conjunto de datos aleatorios, criptográficamente seguros se pueden exprimir por completo los datos privados, para descifrarlos se necesita el pad de un sólo uso. Esta forma de cifrado es ideal para la comunicación de datos sensibles, salvo una desventaja, que primero hay que transferir el pad de un sólo uso a la otra parte. Es posible descargar el HardEncrypt desde la siguiente dirección: http://www.csuglab.cornell.edu/Info/People/jcr13/HardenedCriminal/main.html∞

Secret-share

El secret-share te permite dividir un fichero en tantos trozos como se deseen, todos los cuales se necesitan para reconstruir satisfactoriamente el fichero. Todos los trozos menos uno son datos aleatorios cifrados, lo cual lo enmaraña de alguna forma. Se puede descargar de: http://www.mindrot.org/code/secret-share.php3∞



Cifrado del disco duro

CFS (Sistema de Ficheros Criptográfico)

El CFS te permite guardar los datos en el disco duro en formato cifrado, y es significativamente más sencillo de utilizar que un programa de cifrado de ficheros (como PGP) si lo que se quiere es almacenar muchos ficheros y directorios de los que se quiere tener alejados a los curiosos. El sitio oficial de distribución está en: http://www.cryptography.org/∞, y también se encuentran disponibles RPM’s en: ftp://ftp.replay.com/pub/replay/linux/Red Hat/∞, y los ficheros binarios Debian están en: http://www.debian.org/Packages/stable/otherosfs/cfs.html∞.



TCFS

El TCFS es una utilidad de cifrado de datos a nivel del kernel, similar al CFS. Sin embargo tiene algunas ventajas sobre el CFS; puesto que está implementado en el kernel, es significativamente más rápido. Está fuertemente arraigado con el NFS, lo cual quiere decir que se pueden servir datos de forma segura en una máquina local, o a través de la red. Descifra datos en la máquina cliente, de modo que cuando se utiliza sobre la red, nunca se transmite la contraseña. La única pega es que todavía no se ha adaptado a la serie 2.2 del kernel. El TCFS se puede conseguir en: http://tcfs.dia.unisa.it/∞



PPDD

El PPDD permite crear una partición de disco cifrada, puede ser una partición real o un dispositivo loopback (el cual reside en un fichero, pero se monta como un sistema de ficheros). Utiliza el algoritmo blowfish, el cual es relativamente rápido y está probado. El PPDD se puede conseguir desde: http://linux01.gwdg.de/~alatham/∞



Directorio Raíz Cifrado

El Encrypted Home Directory, Directorio Raíz Cifrado, funciona de forma parecida al CFS, sin embargo está orientado a proporcionar un sólo directorio cifrado. Resumiendo, crear un fichero de tamaño X en /crypt/ con tu UID, y lo monta en un dispositivo loopback de forma que se pueda acceder a él. El truco está en que los datos se cifran y descifran al vuelo, cuando se accede a él (como con el CFS). La única pega es que el software todavía está en desarrollo, así que haz copia de seguridad de cualquier dato importante. Se puede descargar desde: http://members.home.net/id-est/∞




StegFS

Steganographic File System, en realidad oculta los datos en tu disco duro, haciendo difícil incluso probar que existan. Puede ser muy útil, puesto que el atacante primero tiene que encontrar los datos, y ya no digamos romper el fuerte cifrado utilizado para protegerlos. Se puede conseguir de: http://ban.joh.cam.ac.uk/~adm36/StegFS/∞.




BestCrypt

BestCrypt es un producto comercial, con código fuente, disponible para Windows y Linux. Se puede conseguir aquí: http://www.jetico.com/∞






Fuentes de datos aleatorios

Para que el cifrado sea efectivo, especialmente a gran escala como con IPSec a lo largo de muchos hosts, se necesitan buenas fuentes de datos aleatorios y criptográficamente seguros. En Linux, están el /dev/random y el /dev/urandom, que son buenos pero no siempre fenomenales. Parte de la ecuación está en medir sucesos "aleatorios", manipulando esos datos y después poniéndolo disponible (vía (u)random). Estos sucesos aleatorios incluyen: entrada de teclado y ratón, interrupciones, lecturas de disco, etc.

Sin embargo, a medida que los discos duros que van saliendo tienen más y más caché (los IBM Desktstars vienen con 4 Megabytes de caché en disco) y muchos servidores no tienen teclado/ratón, puede ser más difícil encontrar fuentes de datos aleatorios. Algunas fuentes, como la actividad de red, no son del todo apropiadas, puesto que los ataques también se pueden medir (por supuesto que sería un ataque muy exótico, pero lo suficiente como para preocupar a la gente). Existen varias fuentes de datos aleatorios que se pueden utilizar (o al menos que parecen ser aleatorios), los decaimientos radiactivos y las manipulaciones de radiofrecuencias son dos bastante famosos. Por desgracia, la idea de colocar un dispositivo radiactivo al lado de un ordenador suele poner nerviosa a la mayoría de la gente. Y utilizar frecuencias de radio manipuladas está sujeto a error, y la posibilidad de manipulación externa. Para la mayoría de nosotros, no es algo a tener demasiado en cuenta, sin embargo para pasarelas IPSec que manejan muchas conexiones, puede presentar un problema. Una solución potencial es el PIII, que viene con un generador aleatorio de números, que mide la variación térmica de la CPU, creo que a medida que progresemos serán más comunes soluciones como esta.

Ocultación de datos

Un aspecto que olvida mucha gente es que el simple hecho de cifrar los datos puede llamar la atención. Por ejemplo, si un administrador corporativo buscase entre las estaciones de trabajo por ficheros terminados en .pgp, y fueses el único con semejante tipo de ficheros

StegHide

El StegHide oculta los datos en ficheros, tales como sonidos e imágenes, en los cuales no se utilizan todos los bits de cada byte. Puesto que los datos van cifrados, pareceran aleatorios, y probar que los datos están ahí puede ser difícil. La única desventaja es que para almacenar un fichero de un megabyte se necesita una imagen o sonido de varios megabytes, lo cual puede resultar extraño (pero los discos duros y las altas velocidades de acceso se están poniendo baratas). El StegHide se puede conseguir en: http://www2.crosswinds.net/~shetzl/steghide/∞

Virtual Private Server

El Virtual Private Server (VPS) utiliza Perl y SSH para crear VPN’s. Se puede conseguir en: http://www.strongcrypto.com/∞.




Virtual Tunnel

El Virtual Tunnel (VTUN) soporta una variedad de métodos de establecimiento de un enlace, y varios algoritmos. Se puede conseguir de: http://vtun.netpedia.net/∞.

Zebedee

Zebedee proporciona cifrado del tráfico TCP entre hosts y se encuentra disponible para UNIX y windows. Se puede conseguir de: http://www.winton.org.uk/zebedee/∞.

Seguridad IP (IPSec)

Seguridad IP (IPSec) es el cifrado del tráfico de red. No se puede cifrar la información de la cabecera ni el trailer (p. ej. la dirección IP y puerto de donde viene el paquete y su destino, los checksums de CRC, etc.), pero se puede cifrar la carga útil. Esto permite asegurar protocolos como POP/WWW sin tener que cambiarlos de ninguna forma, puesto que el cifrado se hace en el nivel IP. También permite conectar de forma segura LANs y clientes entre sí, sobre redes inseguras (como Internet). En la actualidad, IPSec para Linux está en fase de pruebas, sin embargo ya se han lanzado varias versiones estables, y yo mismo he desarrollado servidores seguros basados en IPSec. IPSec es un standard, y parte el protocolo IPv6, de modo que ya se puede comprar software IPSec para Windows 95/98/NT, Solaris y otros Unix, que interoperarán con Linux IPSec.



Soporte IPSec del kernel

Para utilizar IPSec es necesario tener soporte IPSec en el kernel. Desafortunadamente, ninguna distribución Americana de Linux puede exportar criptografía robusta fuera de Norte América, de modo que en general, suelen escoger no incluirla en absoluto, de las distribuciones extranjeras de Linux, en la actualidad ninguna viene con soporte IPSec dentro del kernel. Es necesario conseguir el código fuente del kernel (recomiendo la 2.2.10, la más reciente a la hora de escribir esto), y el código fuente del Linux IPSec, disponible en: http://www.xs4all.nl/~freeswan/∞

Instala el fuente del kernel (generalmente en /usr/src/linux) y compila el nuevo kernel, instálalo, arráncalo y pruébalo. Asegúrate de que tus redes funcionan correctamente, si no funcionan, hacer que lo haga IPSec será imposible. Ahora hay que descargar la última instantánea de IPSec (la versión 1.0 NO funcionará con los kernels 2.2.x). Después ir a /usr/local/src (o dondequiera que hayas puesto el código fuente de tus programas), desempaquetar el fuente y ejecutar el programa de instalación (make menugo suele ser lo habitual para la configuración basada en ncurses). Lo cual parcheará los ficheros del kernel, luego ejecuta la configuración del kernel y después construye las herramientas IPSec y el kernel.

cd /usr/local/src/

tar –zvvxf /path/del/tarball/snapshot.tar.gz

chown –R root:root freeswan-snap1999Jun14b

cd freeswan-snap1999Jun14b

make menugo

asegúrate de guardar la configuración del kernel, incluso aunque se hayan elegido las opciones, no han sido guardadas. También tendrás que reconstruir el kernel, puesto que el comando "make menugo" ejecuta un "make zImage", lo cual suele fallar, debido a los grandes tamaños del kernel de la 2.2.x. Una vez que se ha hecho la compilación, debería dar uno o dos mensajes de error, simplemente haz:

cd /usr/src/linux

make bzImage

cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.10-ipsec

Ahora hay que editar lilo.conf, ejecutar lilo de nuevo y reiniciar para hacer uso del nuevo kernel.

lilo.conf debería tener el siguiente aspecto:

boot=/dev/hda

map=/boot/map

install=/boot/boot.b

prompt

timeout=100

image=/boot/vmlinuz-2.2.10-ipsec

label=linux-ipsec

root=/dev/hda1

read-only

image=/boot/vmlinuz-2.2.10

label=linux

root=/dev/hda1

read-only

vuelve a ejecutar lilo y verás:

linux-ipsec *

linux

después reinicia y deberías estar ejecutando el kernel 2.2.10 con soporte IPSec. A medida que la máquina se reinicia y empieza el IPSec se verán varios errores, por defecto IPSec está configurado para utilizar el interfaz eth999, el cual por supuesto no existe. Deberías añadir /usr/local/lib/ipsec en la frase del path o si no tendrás que escribir el path completo un montón.



Configuración de redes IPSec

Tendrás que habilitar el TCP-IP forwarding en el servidor de enlace, en Red Hat Linux se hace cambiando la línea de /etc/sysconfig/network:

FORWARD_IPV4="false"

por:

FORWARD_IPV4="yes"

o se puede habilitar vía sistema de ficheros en /proc:

cat 1 > /proc/sys/net/ipv4/ip_forward

Puesto que la mayoría de la gente tiene por defecto políticas de denegación de paquetes de forwarding, tendrás que permitir que los paquetes atraviesen la rede remota / máquina de tu red / máquina y vice versa. Además de esto, cualquier regla de enmascaramiento para redes internas que también estén usando IPSec debe venir después de las reglas que permiten el tráfico IPSec, o la máquina intentará enmascarar los paquetes, en lugar de pasarlos al IPSec.

El siguiente ejemplo es para dos redes protegidas (usando direcciones IP no rutables, escondidas tras máquinas Linux haciendo enmascaramiento de IPs) conectadas vía Internet:

10.0.0.2 192.168.0.2

10.0.0.1 192.168.0.1

1.2.3.4 5.6.7.8

1.2.3.1 5.6.7.1

2.3.4.5 6.7.8.9

INTERNET



Conexión manual de llaves

Primero configuraremos un enlace utilizando la conexión manual de llaves (por simplicidad), hay que editar ipsec.conf, y las reglas del cortafuegos. La mayoría de las opciones por defecto del fichero ipsec.conf son correctas, pero hay que cambiar lo siguiente:

conn ejemplo

type=tunnel

left=

leftnexthop=

leftsubnet=

right=

rightnexthop=

rightsubnet=

spibase=0x200

esp=3des-md5-96

espenckey=

espauthkey=

reemplaza la espenckey y la espauthkey con las nuevas llaves (utilizando ranbits para generar un número, recuerda dejar el 0x por delante, que especifica que es un número hexadecimal) de modo que es algo así:

conn mi-tunel

type=tunnel

left=1.2.3.4

leftnexthop=1.2.3.1

leftsubnet=10.0.0.0/24

right=5.6.7.8

rightnexthop=5.6.7.1

rightsubnet=192.168.0.0/24

spibase=0x200

esp=3des-md5-96

espenckey=cualquier_llave_de_autentificación (ranbits 192)

espauthkey=cualquier_otra_llave (ranbits 128)

Una vez que has acabado, copia los ficheros ipsec.conf e ipsec.secrets desde la máquina en que los editaste hasta el otro servidor, de forma segura. Ahora, lo único que queda es añadir reglas al cortafuegos para que no se enmascaren los paquetes (en lugar de eso lo que queremos es redirigirlos, hacer un forward).

En el servidor 1.2.3.4 se deberían añadir las siguientes reglas:

ipchains –A forward –p all –j ACCEPT –s 10.0.0.0/24 –d 192.168.0.0./24

ipchains –A forward –p all –j ACCEPT –s 192.168.0.0/24 –d 10.0.0.0/24

asegúrate de que estas reglas aparecen antes de la regla de enmascaramiento, algo así:

#

# FORWARD RULES

#

ipchains –P forward DENY

#

ipchains –A forward –p all –j ACCEPT –s 10.0.0.0/24 –d 192.168.0.0/24

ipchains –A forward –p all –j ACCEPT –s 192.168.0.0/24 –d 10.0.0.0/24

ipchains –A forward –p all –j MASQ –s 10.0.0.0/24 –d 0.0.0.0/0

Y en el servidor 5.6.7.8 se repetiría el proceso:

ipchains –A forward –p all –j ACCEPT –s 192.168.0.0/24 –d 10.0.0.0/24

ipchains –A forward –p all –j ACCEPT –s 10.0.0.0/24 –d 192.168.0.0/24

asegúrate de que estas reglas aparecen antes de la regla de enmascaramiento, algo así:

#

# FORWARD RULES

#

ipchains –P forward DENY

#

ipchains –A forward –p all –j ACCEPT –s 192.168.0.0/24 –d 10.0.0.0/24

ipchains –A forward –p all –j ACCEPT –s 10.0.0.0/24 –d 192.168.0.0/24

ipchains –A forward –p all –j MASQ –s 192.168.0.0/24 –d 0.0.0.0/0

Ahora deberías ser capaz de establecer el túnel ipsec manualmente en ambas máquinas, y las máquinas de la Red A deberían ser capaces de hablar con las máquinas de la red B sin problemas.

ipsec manual –up mi-tunel

lo cual mostraría una salida similar a:

/usr/local/lib/ipsec/spi: message size is 36

/usr/local/lib/ipsec/spi: message size is 132

/usr/local/lib/ipsec/spi: message size is 132

Para probarlo, haz un ping a 192.168.0.2 desde el cliente 10.0.0.2. Si funciona, lo has configurado correctamente. Si no funciona, verifica tu red para asegurarte de que 1.2.3.4 puede ver 5.6.7.8 y que está habilitado el TCP-IP forwarding, y asegúrate de que no hay reglas del cortafuegos que estén bloqueando paquetes o intentando enmascararlos. Una vez que has establecido y probado la conexión con éxito, deberías pasar a la conexión automática de llaves (especialmente en entornos de producción).



Conexión automática de llaves

Si se intenta usar IPSec en un entorno de producción, la conexión manual de llaves es una mala idea, en términos generales. Con la conexión automática se tiene un secreto compartido de 256bit que se copia a ambos lados del túnel, el cual se utiliza durante el intercambio de llaves para asegurarse que no se dan ataques del tipo "man in the middle, hombre de por medio". Con la conexión automática, la vida media de una llave es de 8 horas, lo cual se puede ajustar a cualquir intervalo, y si alguien se las arregla para atacar por fuerza bruta la llave, sólo será válida durante ese período de tráfico de 8 horas. El ejemplo siguiente se construye sobre el anterior:

ipsec.secrets contiene el secreto compartido. Este fichero debe ser puesto a salvo a toda costa. Para una conexión entre los servidores 1.2.3.4 y 5.6.7.8 se necesitaría una línea como:

1.2.3.4 5.6.7.8

"0xa3afb7e6_20f10d66_03760ef1_9019c643_a73c7ce0_91e46e84_ef6281b9_812392bf"



Esta línea necesita estar en ambos ficheros ipsec.secrets. Después se necesitaría editar la configuración del túnel en ipsec.conf por la siguiente:

conn mi-tunel

type=tunnel

left=1.2.3.4

leftnexthop=1.2.3.1

leftsubnet=10.0.0.0/24

right=5.6.7.8

rightnexthop=5.6.7.1

rightsubnet=192.168.0.0/24

keyexchange=ike

keylife=8h

keyingtries=0

Entonces se arrancaría el demonio pluto, intenta conectar al demonio Pluto desde el otro extremo del túnel, y establece una conexión. Una advertencia, Pluto se ejecuta en el puerto 500, udp, de modo que lo más probable es que tengas que abrir un hueco en el cortafuegos para permitirle pasar:

ipchains –A input –p udp –j ACCEPT –s 0.0.0.0/0 –i eth0 –d 0.0.0.0/0 500



Encuentro conveniente el uso de la clave "%search" en lugar de listar el túnel a arrancarse, añadiendo:

auto=start

para cada configuración del túnel y editar el ipsec.secrets:

plutoload=%search

plutostart=%search

Lo cual a la larga te hará la vida más fácil. Si todo va bien, deberías ver algo parecido a esto en /var/log/messages:

|| Jun 26 02:10:41 server ipsec_setup: Starting FreeS/WAN IPSEC... Jun 26 02:10:41 server ipsec_setup: /usr/local/lib/ipsec/spi: message size is 28 Jun 26 02:10:41 server ipsec_setup: KLIPS debug ‘none’ Jun 26 02:10:41 server ipsec_setup: KLIPS ipsec0 on eth0 1.2.3.4/255.255.255.0 broadcast 24.108.11.255 Jun 26 02:10:42 server ipsec_setup: Disabling core dumps: Jun 26 02:10:42 server ipsec_setup: Starting Pluto (debug ‘none’): Jun 26 02:10:43 server ipsec_setup: Loading Pluto database ‘mi-tunel’: Jun 26 02:10:44 server ipsec_setup: Enabling Pluto negotiation: Jun 26 02:10:44 server ipsec_setup: Routing for Pluto conns ‘mi-tunel’: Jun 26 02:10:45 server ipsec_setup: Initiating Pluto tunnel ‘mi-tunel’: Jun 26 02:10:45 server ipsec_setup: 102 "mi-tunel" #1: STATE_MAIN_I1: initiate Jun 26 02:10:45 server ipsec_setup: 104 "mi-tunel" #1: STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, expecting MR2 Jun 26 02:10:45 server ipsec_setup: 106 "mi-tunel" #1: STATE_MAIN_I3: from STATE_MAIN_I2;sent MI3, expecting MR3 Jun 26 02:10:45 server ipsec_setup: 003 "mi-tunel" #1: STATE_MAIN_I4: SA established Jun 26 02:10:45 server ipsec_setup: 110 "mi-tunel" #2: STATE_QUICK_I1: initiate Jun 26 02:10:45 server ipsec_setup: 003 "mi-tunel" #2: STATE_QUICK_I2: SA established Jun 26 02:10:46 server ipsec_setup: ...FreeS/WAN IPSEC started ||

Y en el fichero /var/log/secure se debería ver algo parecido a esto:

|| Jun 26 02:10:42 server Pluto[25157]: Starting Pluto (FreeS/WAN Version snap1999Jun14b Jun 26 02:10:42 server Pluto[25157]: added connection description "mi-tunel" Jun 26 02:10:42 server Pluto[25157]: listening for IKE messages Jun 26 02:10:42 server Pluto[25157]: adding interface ipsec0/eth0 1.2.3.4 Jun 26 02:10:42 server Pluto[25157]: loading secrets from "/etc/ipsec.secrets" Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #1: initiating Main Mode Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #1: ISAKMP SA established Jun 26 02:10:42 server Pluto[25157]: "seifried-mosqueado" #2: initiating Quick Mode POLICY_ENCRYPT+POLICY_TUNNEL+POLICY_PFS Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #2: sent QI2, IPsec SA established Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #3: responding to Main Mode Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #3: sent MR3, ISAKMP SA established Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #4: responding to Quick Mode Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #4: IPSec SA established Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #5: responding to Main Mode Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #5: sent MR3, ISAKMP SA established Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #6: responding to Quick Mode Jun 26 02:10:42 server Pluto[25157]: "mi-tunel" #6: IPsec SA established ||

Además de esto se puede ver la salida de "eroute" para asegurarse de que los túneles están correctamente configurados:

10.0.0.0/24 -> 192.168.0.0/24 => tun0x114@1.2.3.4

Y si le echas un vistazo a tus rutas ("route"), deberías ver:

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

1.2.3.4 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth1

1.2.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

1.2.3.0 0.0.0.0 255.255.255.0 UG 0 0 0 ipsec0

192.168.0.0 1.2.3.1 255.255.255.0 UG 0 0 0 ipsec0

10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

0.0.0.0 1.2.3.1 0.0.0.0 UG 0 0 0 eth0



Productos IPSec comerciales

He pensado que sería interesante hacer un breve listado de los productos IPSec comerciales, por supuesto haciendo énfasis en los basados en Linux y FreeS/WAN

i-data

i-data desarrolla una línea de productos que incluyen un servidor VPN, basado en Linux y en FreeS/WAN. Están ubicados en Dinamarca, lo cual les permite que su producto esté disponible para todo el mundo. El sitio web está en: http://www.i-data.com/networks/∞

Productos IPSec para Windows

También existen paquetes de software que proporcionan capacidad de IPSec para Windows, uno de los cuales incluso es gratuito.

PGP VPN

Los autores de PGP (Network Associates) han creado un paquete de software "PGP VPN" (que tiene muy poco que ver con PGP). Soporta IPSec y se dice que también opera con Linux FreeS/WAN. Se puede conseguir en: http://www.nai.com/asp_set/products/tns/pgp_vpn.asp∞

IRE

http://www.ire.com∞

Seguridad PPP

PPP permite conexiones TCP-IP, IPX/SPX y NetBEUI sobre líneas serie (las cuales pueden estar conectadas a módems, por supuesto). Este es el método principal que utiliza la gente para conectarse a Internet (prácticamente todas las cuentas de dial-up son PPP). La esencia de una conexión PPP consiste en dos dispositivos informáticos (un ordenador, un Palm Pilot, un servidor de terminales, etc.) conectados sobre enlaces de serie (generalmente vía módems). Ambos extremos llaman al PPP, se negocia la autentificación (mediante uno de entre varios métodos), y se establece el enlace. PPP no tiene soporte real para cifrado, de modo que si se necesita un enlace seguro hay que invertir en algún tipo de software VPN.

La mayoría de los sistemas llaman a PPP de una forma bastante cutre, se hace un login al equipo (servidor de terminales, etc.) y luego se invoca al login shell del PPP. Por supuesto que esto significa que el nombre de usuario y contraseña se envían en texto claro sobre la línea, y que hay que tener una cuenta en ese tipo de equipo. En este caso el PPP no negocia la autentificación en absoluto. Un método algo más seguro de gestionarlo es utilizar PAP (Password Authentification Protocol, Protocolo de Autentificación de Contraseñas). Mediante PAP, la autentificación se hacer internamente mediante PPP, de modo que no se requiere una cuenta "real" en el servidor. Sin embargo el nombre de usuario y la contraseña se siguen enviando en texto claro, pero al menos el sistema es algo más seguro dada la inexistencia de cuentas de usuario "reales".

El tercer (y mejor) método para la autentificación es utilizar CHAP (Challenge Handshake Authentication Protocol, Protocolo de Autentificación Desafío-Respuesta). Ambas partes se intercambian llaves públicas y las utilizan para cifrar los datos que se envían durante la secuencia de autentificación. De modo que el nombre de usuario y la contraseña están relativamente a salvo de fisgones, y sin embargo las transmisiones de datos se hacen con normalidad. Una advertencia con CHAP: La implementación de Microsoft utiliza DES en lugar de MD5, lo cual lo hace fallar si se conecta con un cliente Linux. Sin embargo existen parches para arreglarlo. PPP viene con cada distribución de Linux como parte del núcleo del SO, el Linux PPP-HOWTO se encuentra disponible en http://www.interweft.com.au/other/ppp-howto/ppp-howto.html

TCP-IP y seguridad de redes

El TPC-IP se creó en una época y en una situación donde la seguridad no era algo que concerniera demasiado. Inicialmente, ‘Internet’ (entonces llamada Arpanet), consistía en unos pocos hosts, todo eran sitios académicos, grandes empresas o gobiernos. Todo el mundo se conocía, y acceder a Internet era un asunto serio. La suite de protocolos TCP-IP es bastante robusta (todavía no ha fallado estrepitosamente), pero desafortunadamente no está prevista para la seguridad (p. ej., autentificación, verificación, cifrado, etc.). Hacer spoofing de paquetes, interceptar paquetes, leer la carga de los datos, y demás, es algo bastante fácil en el Internet de hoy en día. Los ataques más comunes son los ataques de negación de servicio, ya que son los más fáciles de ejecutar y los más difíciles de impedir, seguidos del sniffing de paquetes, escaneo de puertos y otras actividades relacionadas.

Los nombres de hosts no apuntan siempre a la dirección IP correcta, y las direcciones IP’s no siempre se pueden resolver al nombre de host adecuado. Si es posible, no utilices autentificación basada en nombres de hosts. Puesto que el envenenamiento de cachés DNS es algo relativamente sencillo, confiar la autentificación en una dirección IP reduce el problema al spoofing, lo cual es algo más seguro, pero de ningún modo completamente seguro. No existen mecanismos extendidos para verificar quién envió los datos y quién los está recibiendo, excepto mediante el uso de sesiones o cifrado a nivel IP (sin embargo están empezando a cobrar auge el IPSec/IPv6 y otras tecnologías VPN).

Se puede empezar por denegar los datos entrantes que dicen originarse desde tu red(es), puesto que estos datos son evidentemente falsos. Y para evitar que tus usuarios, u otros que hayan irrumpido en tu red puedan lanzar ataques falsificados, se deberían bloquear todos los datos salientes que no provengan de tu dirección IP. Es algo relativamente fácil y sencillo de gestionar, pero la inmensa mayoría de redes no lo hacen (me pasé casi un año dando la coña a mi PSI antes de que empezaran a hacerlo). Si todo en Internet tuviera filtros salientes (es decir, restringir todo el tráfico saliente a aquel que se originase desde las direcciones IP internas), los ataques mediante spoofing serían imposibles, y a la vez sería mucho más fácil tracear el origen de los atacantes. También se deberían bloquear las redes reservadas (127.*, 10.*, etc.). Me he dado cuenta de que muchos ataques provenientes de Internet lo hacen con IPs etiquetadas con esos rangos de direcciones. Si se utiliza traducción de direcciones de red (como IPMASQ) y no se tiene correctamente instalado el cortafuegos, se puede ser atacado con facilidad, o ser utilizado para lanzar un ataque a terceros.

Si tienes que comunicarte de forma segura con otra gente, deberías considerar el uso de la tecnología VPN. La única tecnología disponible que goza de una amplia aceptación y está destinada a convertirse en standard (en IPv6) es IPSec, un standard abierto soportado por muchos vendedores y la mayoría de los vendedores tienen implementaciones funcionales nativas para sus SO (aunque algunas están limitadas para cumplir con las leyes de exportación de los EE.UU.). Por favor, lee el Apéndice B o la sección Cifrado de Servicios y Datos para más detalles.



IPSec

El IPSec tiene su propia sección∞. Creo que es el futuro de la tecnología VPN (es el standard más comúnmente aceptado en la actualidad, y una parte integral de IPv6).



IPv6

IPv6 no proporciona seguridad per se, pero tiene conectores integrados para futuras mejoras de seguridad, soporte para IPSec, etc. Si se utiliza en una red, por supuesto que haría más difícil la vida de los atacantes, puesto que el uso de IPv6 todavía no está muy extendido. Si quieres aprender más, visita http://www.bieringer.de/linux/IPv6/∞. Actualmente, Linux soporta IPv6 casi completamente (uno de los pocos SO’s que lo hacen).



Programas de ataque TCP-IP

Existen una variedad de programas para causar desorganización en TCP-IP (la mayoría son ataques de Negación de Servicio) sin embargo sólo unos pocos pueden ser útiles para administradores.

Proyecto HUNT

El Proyecto HUNT es un conjunto de herramientas para manipular conexiones TCP-IP (generalmente en una LAN Ethernet), como cerrar conexiones, espiarlas y otro tipo de cosas "desagradables". Incluye también una variedad de ataques basados en ARP y otro tipo de maléficas fuentes de diversión. Se puede conseguir en: http://www.cri.cz/kra/index.html∞

Ficheros basicos de configuración de red

Hay varios ficheros de configuración importantes, que controlan qué servicios ejecuta Linux y cómo lo hacen. Por desgracia, muchos de ellos se encuentran en diferentes localizaciones dependiendo de qué/cómo instalaras Linux y los servicios. Los lugares habituales son:

Fichero de configuración del servidor Inetd:

/etc/inetd.conf

Ficheros de inicio de varios tipos:

/etc/rc.d/*

/etc/*

Lo mejor que se puede hacer es imaginarse qué servicios se quiere ejecutar, y deshabilitar/borrar el resto. Échale un vistazo a la sección apropiada de gestión de paquetes de tu sistema (RPM, dpkg, tarballs)



inetd.conf

inetd.conf es el responsable de iniciar los servicios, generalmente aquellos que no necesitan ejecutarse de continuo, o que están basados en sesiones (como telnet o ftpd). Ello es debido a que la sobrecarga que supondría ejecutar un servicio constantemente (como telnet) sería mayor que el costo de inicio ocasional (o que arrancar in.telnetd) cuando el usuario quisiera utilizarlo. Para algunos servicios (como DNS) que sirven a muchas conexiones rápidas, la sobrecarga de arrancar servicios cada pocos segundos sería mayor que tenerlo constantemente ejecutándose. De igual forma ocurre con servicios como DNS y el correo, donde el tiempo es crítico, sin embargo unos pocos segundos de retraso en empezar una sesión de ftp no le hacen daño a nadie. La página del manual de inetd.conf cubre los básicos ("man inetd.conf"). El servicio en sí se llama inetd y se ejecuta al arrancar, de modo que se le puede parar/arrancar/recargar manipulando el proceso inetd. Cada vez que se hagan cambios a inetd.con, hay que reiniciar inetd para hacer efectivos los cambios, killall –1 inetd lo reiniciará correctamente. Como de costumbre, las lineas del inetd.conf se pueden comentar con un # (lo cual es una forma muy simple y efectiva de deshabilitar servicios como rexec). Se aconseja desabilitar tantos servicios de inetd.conf como sea posible, por lo general los que se suelen usar son ftp, pop e imap. Se debería reemplazar telnet y los servicios r por el SSH y servicios como systat/netstat y finger proporcionan demasiada información. El acceso a programas arrancados por inetd se puede controlar con facilidad mediante el uso de TCP_WRAPPERS.



TCP_WRAPPERS

Usar TCP_WRAPPERS hace que el asegurar servidores contra intrusiones externas sea bastante más simple y menos doloroso de lo que te imaginas. TCP_WRAPPERS se controla desde dos ficheros:

/etc/hosts.allow

/etc/hosts.deny

Primero se comprueba hosts.allow, y las reglas se comprueban desde la primera a la última. Si encuentra una regla que te permita específicamente entrar (p. ej., una regla que permita a tu host, dominio, máscara de subred, etc.) te deja conectarte al servicio. Si no puede encontrar ninguna regla que te corresponda en hosts.allow, entonces va a comprobar hosts.deny en busca de una regla que te deniegue la entrada. De nuevo comprueba las reglas de hosts.deny desde la primera a la última, y la primera regla que encuentre que te deniega acceso (p. ej., una regla que deshabilite tu host, dominio, máscara de subred, etc.) significa que no te deja entrar. Si tampoco puede encontrar una regla denegándote la entrada, entonces por defecto te deja entrar. Si eres tan paranoico como yo, la última regla (o la única regla si se va a utilizar una política por defecto no optimista en cuanto a seguridad) debería ser:

ALL: 0.0.0.0/0.0.0.0

lo que significa que todos los servicios, todos los lugares, de modo que cualquier servicio al que no se le permita específicamente acceder, queda bloqueado (recuerda que por defecto es permitir). Quizás también preferirías simplemente denegar el acceso por defecto a, digamos, telnet, y dejar el ftp abierto al mundo. Habría que hacer lo siguiente:

en hosts.allow:

in.telnetd: 10.0.0.0/255.255.255.0 # permitir acceso desde la red interna de 10.0.0.*

in.ftpd: 0.0.0.0/0.0.0.0 # permitir acceso desde cualquier parte del mundo

en hosts.deny:

in.telnetd: 0.0.0.0/0.0.0.0 # denegar acceso a telnetd desde cualquier parte

o si quieres estar realmente a salvo:

ALL: 0.0.0.0/0.0.0.0 # denegar el acceso a todo desde cualquier parte

Lo cual puede afectar a servicios como ssh y nfs, de modo que ¡ten cuidado!

Quizás simplemente prefieras listar por separado todos los servicios que se están usando:

in.telnetd: 0.0.0.0/0.0.0.0

ipop3d: 0.0.0.0/0.0.0.0

Si se deja activado un servicio que no debería figurar en inetd.conf y NO se tiene una política de denegación por defecto, se pueden tener problemas. Es más seguro (y lleva un poco más de trabajo, pero a la larga es menor que tener que reinstalar el servidor) tener reglas de denegación por defecto para el cortafuegos y TCP_WRAPPERS, de modo que si se olvida algo por accidente, por defecto no tendrá acceso. Si se instala algo para lo cual necesitan tener acceso los usuarios y se olvida poner reglas, enseguida se quejarán y se podrá rectificar el problema rápidamente. Fallar por precaución y denegar accidentalmente algo es más seguro que dejarlo abierto.

Las páginas del manual de TCP_WRAPPERS son bastante buenas y están disponibles haciendo:

man hosts.allow

y/o (son la misma página del manual)

man hosts.deny

Una pequeña advertencia con TCP_WRAPPERS de aparición reciente en Bugtraq.

TCP_WRAPPERS interpreta la líneas de hosts.allow y hosts.deny de la forma siguiente:


1.se eliminan todos los \’s (continuación de línea), completando todas las líneas (también hay que darse cuenta de que la longitud máxima de una línea es de unos 2k, en algunos casos es mejor utilizar múltiples líneas)
2.se eliminan las líneas que empiezan con #’s, p. ej. todas las líneas comentadas. De modo que:

# esto es una prueba

# in.ftpd: 1.1.1.1 \

in.telnetd: 1.1.1.1

esto significa que la línea "in.telnetd: 1.1.1.1" también se ignoraría.



/etc/services

El fichero de servicios es una lista de números de puertos, el protocolo y el nombre correspondiente. El formato es:

nombre-de-servicio puerto/protocolo alias

# comentario opcional

por ejemplo:

time 37/udp timserver

rlp 39/udp resource # localización de recursos

name 42/udp nameserver

whois 43/tcp nicname # generalmente al sri-nic

domain 53/tcp

domain 53/udp

Por ejemplo, este fichero se utiliza cuando se ejecuta ‘netstat -a’, y por supuesto no se utiliza cuando se ejecuta ‘netstat -an’

Seguridad basica de servicios de red

¿Qué se está ejecutando y con quién se está hablando?

No se pueden empezar a segurar servicios hasta que no se sepa qué se está ejecutando. Para este tipo de tareas, ps y netstat no tienen precio; ps dice qué se está ejecutando (httpd, inetd, etc) y netstat te dirá cuál es el estado de los puertos (llegados a este punto, estamos interesados en los puertos que están abiertos y escuchando, es decir, esperando conexiones). Se les puede echar un vistazo a los diferentes ficheros de configuración que controlan los servicios de red.



Salida de PS

El programa ps nos muestra el estado de procesos (información disponible en el sistema de ficheros virtual /proc). Las opciones más comúnmente utilizadas son "ps -xau", que muestra algo así como toda la información que siempre quisiste saber. Por favor, ten en cuenta: estas opciones cambian entre sistemas UNIX, Solaris, SCO, todos se comportan de manera diferente (lo cual es increíblemente molesto). Lo que viene a continuación es una salida típica de una máquina (utilizando "ps -xau").

USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND

bin 320 0.0 0.6 760 380 ? S Feb 12 0:00 portmap

daemon 377 0.0 0.6 784 404 ? S Feb 12 0:00 /usr/sbin/atd

named 2865 0.0 2.1 2120 1368 ? S 01:14 0:01 /usr/sbin/named -u named -g named -t /home/named

nobody 346 0.0 18.6 12728 11796 ? S Feb 12 3:12 squid

nobody 379 0.0 0.8 1012 544 ? S Feb 12 0:00 (dnsserver)

nobody 380 0.0 0.8 1012 540 ? S Feb 12 0:00 (dnsserver)

nobody 383 0.0 0.6 916 416 ? S Feb 12 0:00 (dnsserver)

nobody 385 0.0 0.8 1192 568 ? S Feb 12 0:00 /usr/bin/ftpget -S 1030

nobody 392 0.0 0.3 716 240 ? S Feb 12 0:00 (unlinkd)

nobody 1553 0.0 1.8 1932 1200 ? S Feb 14 0:00 httpd

nobody 1703 0.0 1.8 1932 1200 ? S Feb 14 0:00 httpd

root 1 0.0 0.6 776 404 ? S Feb 12 0:04 init [3]

root 2 0.0 0.0 0 0 ? SW Feb 12 0:00 (kflushd)

root 3 0.0 0.0 0 0 ? SW Feb 12 0:00 (kswapd)

root 4 0.0 0.0 0 0 ? SW Feb 12 0:00 (md_thread)

root 64 0.0 0.5 736 348 ? S Feb 12 0:00 kerneld

root 357 0.0 0.6 800 432 ? S Feb 12 0:05 syslogd

root 366 0.0 1.0 1056 684 ? S Feb 12 0:01 klogd

root 393 0.0 0.7 852 472 ? S Feb 12 0:00 crond

root 427 0.0 0.9 1272 592 ? S Feb 12 0:19 /usr/sbin/sshd

root 438 0.0 1.0 1184 672 ? S Feb 12 0:00 rpc.mountd

root 447 0.0 1.0 1180 644 ? S Feb 12 0:00 rpc.nfsd

root 458 0.0 1.0 1072 680 ? S Feb 12 0:00 /usr/sbin/dhcpd

root 489 0.0 1.7 1884 1096 ? S Feb 12 0:00 httpd

root 503 0.0 0.4 724 296 2 S Feb 12 0:00 /sbin/mingetty tty2

root 505 0.0 0.3 720 228 ? S Feb 12 0:02 update (bdflush)

root 541 0.0 0.4 724 296 1 S Feb 12 0:00 /sbin/mingetty tty1

root 1372 0.0 0.6 772 396 ? S Feb 13 0:00 inetd

root 1473 0.0 1.5 1492 1000 ? S Feb 13 0:00 sendmail: accepting connections on port 25

root 2862 0.0 0.0 188 44 ? S 01:14 0:00 /usr/sbin/holelogd.named /home/named/dev/log

root 3090 0.0 1.9 1864 1232 ? S 12:16 0:02 /usr/sbin/sshd

root 3103 0.0 1.1 1448 728 p1 S 12:16 0:00 su -root 3104 0.0 1.3 1268 864 p1 S 12:16 0:00 -bash

root 3136 0.0 1.9 1836 1212 ? S 12:21 0:04 /usr/sbin/sshd

Los interesantes son: portmap, named, Squid (y su servidor dns, los procesos hijos unlinkd y ftpget), httpd, syslogd, sshd, rpc.mountd, rpc.nfsd, dhcpd, inetd, y sendmail (este servidor parece estar proveyendo servicios de puerta de enlace, correo y compartición de ficheros FNS). La forma más fácil de aprender a leer la salida de ps es irse a la página del manual de ps y aprender a qué se refiere cada campo (la mayoría se explican por sí mismos, tales como el %CPU, mientras que algunos como SIZE son un poco más oscuros: SIZE es el número de páginas de memoria de 4k que está utilizando un programa). Para averiguar qué programas se están ejecutando, una apuesta segura es hacer ‘man ’; lo cual casi siempre suele sacar la página del manual que pertenece a ese servicio (como httpd). Te darás cuenta de que servicios como telnet, ftpd, identd y otros no aparecen aunque estén ahí. Esto es debido a que se ejecutan desde inetd, el "superservidor". Para encontrar estos servicios, mira en /etc/inetd.conf o en la salida de "netstat -vat".



Salida de Netstat

netstat informa acerca de casi cualquier cosa que se pueda imaginar relacionada con la red. Es especialmente buena para sacar listados de conexiones y sockets activos. Al usar netstat se puede encontrar qué interfaces están activas en qué puertos. Lo que viene a continuación es la salida típica de un servidor, con netstat –an.

Active Internet connections (including servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 24.108.11.200:80 205.253.183.122:3661 ESTABLISHED

tcp 0 0 0.0.0.0:1036 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN

tcp 0 0 10.0.0.10:53 0.0.0.0:* LISTEN

tcp 0 0 28.208.55.254:53 0.0.0.0:* LISTEN

tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:635 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN

udp 0 0 127.0.0.1:1031 0.0.0.0:*

udp 0 0 0.0.0.0:1029 0.0.0.0:*

udp 0 0 0.0.0.0:800 0.0.0.0:*

udp 0 0 0.0.0.0:1028 0.0.0.0:*

udp 0 0 10.0.0.10:53 0.0.0.0:*

udp 0 0 28.208.55.254:53 0.0.0.0:*

udp 0 0 127.0.0.1:53 0.0.0.0:*

udp 0 0 10.1.0.1:138 0.0.0.0:*

udp 0 0 10.1.0.1:137 0.0.0.0:*

udp 0 0 10.0.0.10:138 0.0.0.0:*

udp 0 0 10.0.0.10:137 0.0.0.0:*

udp 0 0 0.0.0.0:138 0.0.0.0:*

udp 0 0 0.0.0.0:137 0.0.0.0:*

udp 0 0 0.0.0.0:2049 0.0.0.0:*

udp 0 0 0.0.0.0:635 0.0.0.0:*

udp 0 0 0.0.0.0:514 0.0.0.0:*

udp 0 0 0.0.0.0:111 0.0.0.0:*

raw 0 0 0.0.0.0:1 0.0.0.0:*

raw 0 0 0.0.0.0:6 0.0.0.0:*

En mi opinión la salida numérica es más fácil de leer (una vez que se memoriza /etc/services). Los campos que nos interesan son el primero, el tipo de servicio, el cuarto campo, que es la dirección IP de la interfaz y el puerto, la dirección externa (si no es 0.0.0.0.* significa que alguien le está hablando activamente), y el estado del puerto. La primera línea es un cliente remoto hablando con el servidor de Web de esta máquina (puerto 80). Cuando se ve el servidor www escuchando en 0.0.0.0:80 que significa, todos los interfaces, puerto 80, seguidos del servidor DNS ejecutándose en las 3 interfaces, un servidor samba (139), un servidor de correo (25), un servidor NFS (2049), etc. Observarás listado el servidor de ftp (21), que aunque se ejecuta desde inetd, y aunque actualmente no está en uso (p. ej., no hay nadie activo haciendo un ftp), sale en el listado de la salida de netstat. Lo cual convierte a netstat en una herramienta especialmente útil para averiguar qué es lo que está activo en una máquina, haciendo más sencillo el inventariado en el servidor del software activo e inactivo.



lsof

lsof es un práctico programa cuya idea es similar a la de ps, excepto en que muestra qué ficheros/etc están abiertos, lo cual puede incluir sockets de red. Desafortunadamente, el lsof medio saca bastante información, de modo que será necesario utilizar grep o redireccionarlo mediante less ("lsof | less") para hacerlo más cómodo de leer.

squid 9726 root 4u inet 78774 TCP localhost:2074->localhost:2073 (ESTABLISHED)

squid 9726 root 5u inet 78777 TCP localhost:2076->localhost:2075 (ESTABLISHED)

squid 9726 root 6u inet 78780 TCP localhost:2078->localhost:2077 (ESTABLISHED)

squid 9726 root 7w CHR 1,3 6205 /dev/null

squid 9726 root 14u inet 78789 TCP host1:3128 (LISTEN)

squid 9726 root 15u inet 78790 UDP host1:3130

squid 9726 root 16u inet 78791 UDP host1:3130

squid 9726 root 12u inet 167524 TCP host1:3128->host2:3630 (ESTABLISHED)

squid 9726 root 17u inet 167528 TCP host1:3424->www.ejemplo.org:http (SYN_SENT)

Este ejemplo muestra que se tiene ejecutándose a Squid, escuchando en los puertos 3128 y 3130, las últimas dos líneas muestran una conexión abierta desde un host interno al servidor de Squid y la acción resultante que ha emprendido Squid para cumplir con la solicitud (ir a www.playboy.com) host1 es el servidor de Squid y host2 es la máquina cliente haciendo la petición. Es una herramienta que no tiene precio para hacerse una idea exacta de qué es lo que está ocurriendo con tu servidor en la red. Se puede conseguir lsof con algunas distribuciones. Ten en cuenta que las versiones de losf compiladas para las versiones del kernel 2.0.x no funcionarán con el kernel 2.2.x y vice versa, pues hay bastantes cambios. El sitio primario de lsof es: ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/∞