SERVICIOS DE RED

 

 

 

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:

 

 

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.

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.

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:

 

Victor:x:500:Victor Martin TIrado:/home/victor/./:/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.

 

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

<Directory /*>

AllowOverWrite on

</Directory>

 

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 "<Limit LOGIN>".

 

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

 

<Limit LOGIN>

Order Allow, Deny

Allow from 10.1., 1.2.3.4

Deny from all

</Limit>

 

Si se coloca esto dentro de las directivas "<VirtualHost>" o "<Anonymous>", se aplica sólo a ese sitio virtual o configuración anónima, si se coloca en la directiva "<Global>" se aplicará a todas las secciones "<VirtualHost>" y "<Anonymous>", 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 "<Global>", "<VirtualHost>" o "<Anonymous>".

 

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

 

<Anonymous ~ftp>

User ftp

Group ftp

RequireValidShell off

UserAlias anonymous ftp

MaxClients 10

DisplayLogin bienvenido.msg

DisplayFirstChdir .message

<Directory *>

<Limit WRITE>

DenyAll

</Limit>

</Directory>

</Anonymous>

 

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 "<Directory >" 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 "<Directory *>":

 

<Directory incoming>

<Limit WRITE>

AllowAll

</Limit>

<Limit READ>

DenyAll

</Limit>

</Directory>

 

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.

Simple Mail Transfer Protocol (SMTP), es uno de los servicios más importantes que proporciona Internet. Ahora casi todas las compañías tienen o dependen del correo, y por extensión todos los servidores SMTP. Se encuentran disponibles muchos paquetes SMTP, siendo el más viejo y el más probado el Sendmail (ahora con soporte comercial, etc.), y hay dos nuevos contendientes, Postfix y Qmail, ambos dos escritos desde cero teniendo en cuenta la seguridad. Filtrar con el cortafuegos el SMTP no tiene pérdida, se ejecuta en el puerto 25, tcp:

 

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

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

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

 

o bien con ipchains:

 

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

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

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

 

Sendmail

 

Sendmail es otro de esos servicios con los que la mayoría de nosotros hemos tenido relaciones. Odiamos administrarlo y nos encantaría reemplazarlo (en realidad he empezado a eliminar el Sendmail de las máquinas que administro y lo estoy reemplazando con el Postfix).

 

Sendmail se ha ganado por sí mismo una muy mala reputación en cuanto a seguridad, sin embargo es difícil echarle la culpa al software cuando te encuentras con sistemas ejecutando versiones antiguas del sendmail. La raíz del problema (si se me permite el mal juego de palabras) es que casi todo el mundo ejecuta el sendmail como root (y algo así como el 70% del correo de Internet se maneja mediante máquinas con Sendmail, de modo que hay un montón de ellas), de forma que tan pronto se encuentra un bug, encontrar un sistema que explotar no es tan difícil. Las últimas versiones de sendmail han sido bastante buenas, sin hacks del root, etc, y con las nuevas características anti spam finalmente ha alcanzado la mayoría de edad. Más información en Sendmail y su código fuente está disponible en: http://www.sendmail.org/

 

Hacer un chroot del sendmail es una buena opción, pero lleva demasiado trabajo, y puesto que se ejecuta como root, algo bastante discutible en cuanto a su efectividad (puesto que el root se puede escapar de una cárcel chroot). Personalmente pienso que es mejor invertir el esfuerzo en cambiarse a Postfix o a Qmail.

 

Mantener actualizado el sendmail es relativamente simple, recomendaría como mínimo la versión 8.9.3 (la serie 8.9 tiene más características anti-spam, la 8.8.x tiene la mayoría de estas características, suponiendo que se ha configurado correctamente el sendmail.cf). La mayoría de las distribuciones vienen con la 8.8.x, aunque las versiones más recientes suelen venir con la 8.9.x. Se puede conseguir el código fuente desde ftp://ftp.sendmail.org/, pero compilar el sendmail no es algo para el débil de corazón o para aquellos que no tengan un montón de tiempo para dedicárselo.

 

Sendmail sólo tiene que estar accesible desde el mundo exterior si se está utilizando para recibir correo de otras máquinas y repartirlo localmente. Si sólo se quiere ejecutar sendmail de forma que funcione el reparto local (p. ej., una estación de trabajo autónoma, un servidor de prueba u otros) y que se pueda enviar con facilidad el correo a otras máquinas, simplemente filtra con el cortafuegos el sendmail, o mejor, no lo ejecutes en modo demonio (en el cual escucha conexiones). Sendmail se puede ejecutar en la cola de refresco de un nodo, donde simplemente se "despierta" cada cierto tiempo y procesa el correo local, ya sea distribuyéndolo localmente o enviándolo a través de la red. Para configurar la ejecución del Sendmail en modo cola:

 

edita el script de inicio del Sendmail y cambia la línea que contiene:

 

sendmail –bd –q1h

 

por:

 

sendmail –q1h

 

Ten en cuenta que: si utilizas el sistema para enviar mucho correo quizás prefieras disminuir el tiempo de refresco, quizás "-q15m" (refrescar la cola cada 15 minutos), ahora el correo saliente y el correo interno del sistema se comportarán bien, lo cual a menos que se ejecute un servidor de correo, es perfecto.

 

Ahora vienen todas esas maravillosas características anti-spam del sendmail. Los ficheros de configuración del Sendmail consisten en (se aplica al Sendmail 8.9.x):

 

/etc/sendmail.cf

El fichero de configuración principal, también dice dónde se encuentran el resto de ficheros de configuración.

 

/etc/mail/

Se puede definir la localización de los ficheros de configuración en sendmail.cf, generalmente la gente los coloca en /etc/ o en /etc/mail (lo cual lo lía menos).

 

access

La base de datos de la lista de accesos, permite rechazar el correo proveniente de ciertas fuentes (IP o dominio), y controlar con facilidad las transmisiones. Mi fichero de acceso es así:

 

       

    1. RELAY

       

spam.com REJECT

 

lo que quiere decir que a 10.0.0.* (los hosts de mi red interna) se les permite utilizar el servidor de correo para enviar correo donde quieran, y el correo de *.spam.com se rechaza. Hay listas en línea de spammers conocidos, generalmente suele tener entre 5-10.000 entradas, lo cual puede afectar seriamente el rendimiento del sendmail (pues cada conexión se comprueba contra esta lista), por otra parte, tener una máquina sendmail para enviar spam es incluso peor.

 

aliases

El fichero de alias, te permite controlar el reparto del correo local al sistema, es útil para hacer una copia de seguridad del correo entrante de un usuario a un spool por separado. La mayoría del software de servidores de listas utiliza este fichero para enviar el correo que recibe a los programas que realmente procesan las listas. Recuerda ejecutar el comando "newaliases" después de editar este fichero, y después reiniciar el sendmail.

 

domaintable

la tabla de dominios (añadir dominios) que se maneja, útil para hacer hosting virtual.

 

majordomo

fichero de configuración de majordomo, personalmente recomendaría SmartList a Majordomo.

 

sendmail.cw

fichero que contiene nombres de hosts de los que se recibe correo, útil si se alberga más de un dominio.

 

sendmail.hf

situación del fichero de ayuda (telnet al puerto 25 y escribir "HELP")

 

virtusertable

Tabla de usuario virtual, mapea usuarios entrantes, p. ej., mapear ventas@ejemplo.org a john@ejemplo.org

 

Sendmail 8.9.x (y versiones anteriores) en realidad no tienen soporte para hacer un log de todo el correo de una forma agradable (un requisito indispensable por muchas compañías por motivos legales). Esta es una de las características sobre las que se trabaja en la versión de Sendmail 8.10.x. Hasta entonces, hay dos formas de hacer log del correo, la primera es algo agraciada, y registra un log de los correos entrantes a usuarios según cada usuario. El segundo método no es agraciado, e implica un simple log de todas las transacciones SMTP a un fichero, habría que escribir algún tipo de procesador (probablemente en perl) para que el log fuese útil.

 

El correo (o las conexiones SMTP para ser más precisos) primero se filtra con el fichero access, y es aquí donde se pueden RECHAZAR correos de ciertos dominios/IP’s, y TRANSMITIR correo de ciertos hosts (p. ej. tu red interna de máquinas windows). Cualquier dominio local para el que se hospeda el correo tendrá que ir al sendmail.cw. Suponiendo que el correo cumple con las reglas y va a la cola para reparto local, el siguiente fichero que se comprueba en virtusertable, que es una lista de direcciones de correo mapeadas al nombre de la cuenta/otra dirección de correo. p.ej.:

 

seifried@victor.org alias-seifried

listuser@victor.org usuariolista

@victor.org correos-estropeados

 

La última regla es para evitar que reboten los correos estropeados, y que en lugar de eso se envíen a un buzón. Después se comprueba el fichero de alias, si se encuentra una entrada se hace lo que dice, y si no, se intenta entregar el correo a un buzón de un usuario local, mi entrada seifried del fichero de alias es:

 

alias-victor: victor, "/var/backup-spool/seifried"

 

De esta forma mi correo se reparte a mi buzón normal, y a un buzón de copia de seguridad (por si acaso he borrado un correo que no quisiera), o en el peor de los casos, Microsoft Outlook decide cascar un día y cargarse mis buzones. Esto también sería útil en empresas, puesto que ahora se tiene una copia de seguridad de todo el correo entrante según cada usuario, y se les puede permitir ( o no) acceder al fichero que contiene el correo en la copia de seguridad.

 

Una advertencia, cuando se esté usando una regla general para un dominio ( p. ej. @victor.org) hay que crear un alias para CADA cuenta, y para las listas de correo. Si no, cuando se examina la lista y no se encuentra una entrada específica  lo enviará al buzón especificado por la regla general. Ya sólo por este motivo no se debería utilizar una regla general.

 

El segundo método es muy simple, sencillamente se arranca el sendmail con la opción –x y se especifica un fichero para hacer un log de todas las transacciones. Este fichero crecerá con enorme rapidez, NO recomendaría utilizar este método para hacer log del correo, al menos que sea absolutamente necesario.

DNS


 

 

Bind

 

DNS es un servicio extremadamente importante para redes IP. No dudaría en decir que probablemente sea el servicio MÁS importante (sin él, nadie puede encontrar nada más). También requiere conexiones provenientes del mundo exterior, y debido a la naturaleza y estructura del DNS, la información que los servidores de DNS dicen tener puede no ser cierta. El principal proveedor de software DNS (named, el standard de facto) actualmente está buscando la forma de añadir información de autentificación ( utilizando RSA para firmar criptográficamente los datos, probando que es "cierto"). Si se tiene planeado administrar servidores DNS, yo diría que es de obligada lectura "DNS & BIND", de O’Reilly and Associates.

 

La mayoría de las distribuciones vienen con bind 8.x, sin embargo ninguna (según mis conocimientos) lo trae configurado para no-root, utilizan chroot por defecto. Sin embargo hacer el cambio es sencillo:

 

-u

especifica a qué UID cambiará bind una vez que esté vinculado al puerto 53 (me gusta utilizar un usuario llamado ‘named’ sin permisos de login, similar a ‘nobody’).

 

-g

especifica el directorio al que bind se hará chroot a sí mismo una vez que esté arrancado. /home/named es una buena apuesta, es en este directorio donde se deberían situar todas las librerías y ficheros de configuración que va a necesitar bind.

 

Una forma incluso más sencilla de ejecutar bind con chroot es descargar el paquete bind-chroot, disponible como paquete de contribución en la mayoría de las distribuciones, e instalarlo. Antes de la instalación, se necesitará un usuario y un grupo llamados named (al cual cambiará el servidor bind su UID/GID), simplemente utilizar groupadd y useradd para crear el usuario/grupo. Algunos paquetes utilizan holelogd para hacer un log de la información de bind en /var/log/messages (de igual forma que haría bind). Si no está disponible, habrá que instalarlo a mano, lo cual es una faena. Además de esto, el fichero de configuración por defecto de bind se suele configurar de forma segura (p. ej., no se puede hacer una petición a bind acerca de su versión).

 

Otro aspecto de bind es la información que contiene sobre tu(s) red(es). Cuando alguien hace una petición a un servidor DNS, por lo general envían una petición pequeña por cada información. Por ejemplo, ¿cuál es la dirección IP de www.victor.org? Y existen transferencias de dominios, en las cuales un servidor DNS solicita toda la información disponible sobre, digamos, seifried.org, la recibe y después la pone disponible a otros (en el caso de un servidor DNS secundario). Esto es potencialmente peligroso, ya que puede ser tanto o más peligroso que enviar el número de teléfono de la compañía a cualquiera que llame y lo solicite. La versión 4 de Bind no se preocupaba demasiado sobre la seguridad, se podían limitar las transferencias a ciertos servidores, pero no de la forma lo suficientemente selectiva como para ser realmente útil. Esto ha cambiado en Bind 8, la documentación se encuentra disponible en http://www.isc.org/bind.html. Resumiendo, en Bind 8 existen configuraciones globales, la mayoría de las cuales se pueden aplicar basadas en el dominio. Se pueden restringir con facilidad las transferencias Y las peticiones, hacer log de las peticiones, configurar los tamaños máximos de los datos, etcétera. Recuerda, cuando se está restringiendo las peticiones de zona, se deben asegurar TODOS los servidores de nombres (principal y secundarios), ya que se pueden transferir zonas desde un secundario con igual facilidad que desde el principal.

 

He aquí un fichero de configuración named.conf relativamente seguro (robado del paquete bind-chroot disponible en ftp.tux.org):

 

options {

// Para este chroot se necesitan los siguientes paths

directory "/var/named";

dump-file "/var/tmp/named_dump.db"; // _PATH_DUMPFILE

pid-file "/var/run/named.pid"; // _PATH_PIDFILE

statistics-file "/var/tmp/named.stats"; // _PATH_STATS

memstatistics-file "/var/tmp/named.memstats"; // _PATH_MEMSTATS

// Fin de los paths necesarios

check-names master warn; /* default. */

datasize 20M;

};

zone "localhost" {

type master;

file "master/localhost";

    check-names fail;

    allow-update { 

        none; 

    };

    allow-transfer { 

        any; 

    };

};

zone "0.0.127.in-addr.arpa" {

type master;

file "master/127.0.0";

    allow-update { 

        none; 

    };

    allow-transfer { 

        any; 

    };

};

// Denegar y registrar peticiones de versión excepto desde localhost

zone "bind" chaos {

type master;

file "master/bind";

    allow-query {

        localhost; 

    };

};

zone "." {

type hint;

file "named.zone";

};

zone "ejemplo.org" {

type master;

file "zones/ejemplo.org";

    allow-transfer {

        10.2.1.1;

        10.3.1.1;

    };

};

 

Identd


El servicio identd se utiliza para mapear usuarios/procesos a puertos en uso. Por ejemplo, la mayoría de los servidores irc intentan averiguar quién se está conectando a ellos haciendo una petición identd, lo cual consiste básicamente en preguntarle al servidor identd desde el ordenador cliente qué información tiene sobre un número de puerto, y la respuesta puede varias desde ninguna (si nadie está utilizando ese puerto en particular) a un nombre de usuario, un nombre de grupo, un id de proceso y otra información interesante. La configuración por defecto de la mayoría de las distribuciones es que el identd está activado (es elegante ejecutarlo, los servidores de irc y las versiones más recientes de sendmail comprueban las respuestas de identd), y sólo distribuirán el nombre de usuario. El uso principal del identd es permitir a los sistemas remotos algún tipo de forma de seguir la pista de los usuarios que se están conectando a sus servidores, irc, telnet, correo, u otros, por propósitos de autentificación (no es una buena idea, ya que es muy fácil de falsear). La universidad local de Edmonton requiere que se ejecute el identd si se quiere hacer un telnet a cualquiera de los servidores de shell, principalmente de forma que puedan seguir con rapidez la pista de las cuentas comprometidas.

 

Ejecutar el identd en tu máquina ayudará a otros administradores a la hora de hacer el seguimiento de problemas, puesto que no sólo consiguen la dirección IP y la hora del problema, sino que utilizando identd pueden averiguar el nombre del usuario. Esta forma es una espada de doble filo, mientras que proporciona información útil para seguir a usuarios maliciosos (definitivamente la gente a la que se quiere mantener alejada de los servidores) también se puede utilizar para conseguir información de los usuarios del sistema, lo cual dé como resultado que sus cuentas sean comprometidas. Ejecutar identd en los servidores sólo tiene sentido si están albergando cuentas de shell.

 

Identd soporta bastantes características, y se puede configurar con sencillez para que se ejecute como usuario no-root. Dependiendo de las políticas de seguridad, se puede querer o no dar mucha información, o se puede querer informar lo máximo posible. Simplemente activa la opción en inetd.conf, después en in.identd (las configuraciones por defecto son –l –e –o).

 

-p port

-a address

 

Se puede utilizar para especificar a qué puerto y en qué dirección se enlaza (en el caso de una máquina con IP’s en forma de alias, o a múltiples interfaces), generalmente sólo es útil si se quiere que conecten máquinas internas, puesto que a las máquinas externas probablemente no les sea posible imaginarse a qué puerto se cambió.

 

-u uid

-g gid

 

Se utilizan para configurar el usuario y el grupo bajo el que el identd tendrá privilegios después de conectar al puerto, lo cual da como resultado el ser menos susceptible de comprometer la seguridad del sistema. En cuanto al manejo de la cantidad de información que proporciona:

 

-o

 

Especifica que identd no devuelva el tipo de sistema operativo, decir simplemente "UNKNOWN" es una muy buena opción.

 

-n

 

Hará que identd devuelva números de usuarios (p.ej. su UID) y no el nombre de usuario, lo cual todavía les proporciona suficiente información para ti y para seguir la pista del usuario con facilidad, sin proporcionar valiosas pistas a posibles atacantes.

 

-N

Permite a los usuarios hacer crear un fichero ~/.noident , lo cual forzará que el identd devuelva "HIDDEN-USER" en lugar de información. Esto les permite a los usuarios la opción de tener un cierto grado de privacidad, pero un usuario malicioso lo utilizará para evadir la identificación.

 

-F format

Te permite especificar mucha más información que la standard, cualquier cosa desde el nombre y número del usuario hasta el PID real, nombre de comando, ¡y los argumentos dados! Esto sólo lo recomendaría para uso interno, puesto que es mucha información que los atacantes encontrarían útil.