Linux Original Courseware - Lx4 Advanced Network Administrator

LOC: Linux Original Courseware Correspondiente al Curso LX4: Advanced Network Administrator

Página 1

Tabla de Contenidos Capítulo 1 ............................................................................................................................................................................................ 5 Introducción a iptables.................................................................................................................................................................... 5 ¿Qué es un Firewall?....................................................................................................................................................................... 5 ¿Qué es iptables?............................................................................................................................................................................. 8 Creando un firewall con iptables .................................................................................................................................................... 9 Proteger la propia máquina ......................................................................................................................................................... 9 Firewall de una LAN con salida a internet............................................................................................................................... 11 Firewall de una LAN con salida a internet con DMZ.............................................................................................................. 15 Firewall puro y duro entre redes............................................................................................................................................... 19 Firewall con política por defecto DROP .................................................................................................................................. 22 Depurar el funcionamiento del firewall........................................................................................................................................ 24 Capítulo 2 .......................................................................................................................................................................................... 25 Introducción a Squid ..................................................................................................................................................................... 25 Software necesario ........................................................................................................................................................................ 25 Instalación del software necesario................................................................................................................................................ 25 Antes de continuar ........................................................................................................................................................................ 26 Configuración básica. ................................................................................................................................................................... 26 ¿Que puerto utilizar para Squid? Parámetro http_port............................................................................................................. 26 ¿Cuánta memoria utilizar? Parámetro cache_mem.................................................................................................................. 27 ¿Cuanto desea almacenar de Internet en el disco duro? Parámetro cache_dir ........................................................................ 27 Aviso de problemas con la cache - Parámetro cache_mgr....................................................................................................... 28 Acceso FTP anónimo a Servidores - Parámetro ftp_user ........................................................................................................ 28 Acceso FTP pasivo a traves de un Firewall - Parámetro ftp_passive...................................................................................... 28 Control de acceso ...................................................................................................................................................................... 28 Control de acceso - Listas......................................................................................................................................................... 28 Control de acceso - Reglas........................................................................................................................................................ 29 Aplicando Listas y Reglas de control de acceso. ..................................................................................................................... 29 Cache con aceleración............................................................................................................................................................... 30 Estableciendo el idioma por defecto............................................................................................................................................. 31 Iniciando, reiniciando y añadiendo el servicio al arranque del sistema. ..................................................................................... 31 Ajustes para el Firewall o script de Enmascaramiento de IP....................................................................................................... 32 Use Iptables en lugar de ipchains. ............................................................................................................................................ 32 Re-direccionamiento de peticiones........................................................................................................................................... 32 Script ejemplo de Enmascaramiento de IP con iptables. ......................................................................................................... 33 Capítulo 3 .......................................................................................................................................................................................... 35 Introducción a FTP........................................................................................................................................................................ 35 El ABC de FTP ............................................................................................................................................................................. 35 La relación cliente/servidor ...................................................................................................................................................... 35 ¿Cómo conseguir la última versión de wu-ftpd?.......................................................................................................................... 36 Lectura de los README.......................................................................................................................................................... 36 Compilación e instalación de wu-ftpd...................................................................................................................................... 36 Configuración de wu-ftpd............................................................................................................................................................. 37 Control de acceso a través del archivo /etc/ftpaccess .............................................................................................................. 37 Configuraciones típicas............................................................................................................................................................. 49 Configuración del usuario anónimo ......................................................................................................................................... 49 Configuración del directorio FTP anónimo.............................................................................................................................. 50 Configuración de /etc/ftpaccess................................................................................................................................................ 51 Configuración del directorio /incoming ................................................................................................................................... 51 Usuarios sólo registrados y acceso mixto................................................................................................................................. 52

Página 2

Configuración de un Servidor FTP Virtual .................................................................................................................................. 53 Conclusiones ................................................................................................................................................................................. 53 Capítulo 4 .......................................................................................................................................................................................... 55 Introducción al Cliente FTP.......................................................................................................................................................... 55 Ejecución del Cliente FTP ............................................................................................................................................................ 55 Comandos del Cliente FTP ........................................................................................................................................................... 55 Salir de una sesión de FTP........................................................................................................................................................ 55 Obtener Ayuda .......................................................................................................................................................................... 55 Manipulación de Archivos y Directorios ................................................................................................................................. 56 Transferencia de Archivos ............................................................................................................................................................ 56 Tipos de Transferencia.............................................................................................................................................................. 56 Transferencia Interactiva .......................................................................................................................................................... 56 Transferencia de archivos desde la máquina Remota a la Local ............................................................................................. 57 Transferencia de archivos desde la máquina Local a la Remota ............................................................................................. 57 Capítulo 5 .......................................................................................................................................................................................... 58 Introducción a Servidores de Correo Elecrónico (e-mail) ........................................................................................................... 58 Funciones de los mail servers ....................................................................................................................................................... 58 Relay.......................................................................................................................................................................................... 58 Recolección ............................................................................................................................................................................... 58 Spam y Virus................................................................................................................................................................................. 58 Servidores de e-mail conocidos .................................................................................................................................................... 59 QMail ........................................................................................................................................................................................ 59 SendMail ................................................................................................................................................................................... 59 Postfix........................................................................................................................................................................................ 60 Exim .......................................................................................................................................................................................... 60 SuSE Linux eMail Server 3.1 ................................................................................................................................................... 61 GLMail ...................................................................................................................................................................................... 61 Capítulo 6 .......................................................................................................................................................................................... 62 Introducción a SendMail............................................................................................................................................................... 62 Requisitos previos ..................................................................................................................................................................... 62 Resultados a obtener ................................................................................................................................................................. 62 Requerimientos mínimos .............................................................................................................................................................. 62 Procedimientos.............................................................................................................................................................................. 63 Preparativos............................................................................................................................................................................... 63 Verificando parámetros de red.................................................................................................................................................. 63 Confirmando la instalación de Sendmail.................................................................................................................................. 64 Configurando Sendmail ................................................................................................................................................................ 64 Habilitando los servicios POP3 e IMAP ...................................................................................................................................... 69 ¿Que hacer con el Spam?.............................................................................................................................................................. 70 El Servidor de Nombres (DNS).................................................................................................................................................... 71 Configuración de los clientes de correo ....................................................................................................................................... 72 Capítulo 7 .......................................................................................................................................................................................... 73 Introducción a Horde (WebMail) ................................................................................................................................................. 73 ¿Qué es Horde? ......................................................................................................................................................................... 73 ¿Qué es IMP? ............................................................................................................................................................................ 73 ¿Qué es Turba?.......................................................................................................................................................................... 73 ¿Qué es Kronolith? ................................................................................................................................................................... 73 ¿Qué es Jonah?.......................................................................................................................................................................... 73 ¿Qué es WHUPS? ..................................................................................................................................................................... 73 ¿Qué es Chora? ......................................................................................................................................................................... 73 ¿Qué es Gollem? ....................................................................................................................................................................... 73 Solamente quiero WebMail. ¿Por qué necesito Horde?............................................................................................................... 73 ¿Cuánto cuesta Horde? ............................................................................................................................................................. 74 ¿En qué plataformas funciona Horde? ..................................................................................................................................... 74 ¿Horde funciona en Windows 95 o en NT/2K/XP?................................................................................................................. 74

Página 3

Capítulo 8 .......................................................................................................................................................................................... 75 Introducción a Administración Remota........................................................................................................................................ 75 Diferentes tipos de Administración Remota ................................................................................................................................ 75 Control Remoto......................................................................................................................................................................... 75 Sesión Remota........................................................................................................................................................................... 75 Acceso Remoto ......................................................................................................................................................................... 75 Direcciones Web relacionadas...................................................................................................................................................... 76 Capítulo 9 .......................................................................................................................................................................................... 77 Introducción a TelNet ................................................................................................................................................................... 77 Telnet en Linux ............................................................................................................................................................................. 77 Telnet en Windows 2000 .............................................................................................................................................................. 77 Capítulo 10 ........................................................................................................................................................................................ 79 Introducción a SSH ....................................................................................................................................................................... 79 Software requerido........................................................................................................................................................................ 79 Archivos de configuración............................................................................................................................................................ 79 Procedimientos.............................................................................................................................................................................. 79 Parámetro ListenAddress.......................................................................................................................................................... 79 Parámetro PermitRootLogin..................................................................................................................................................... 79 Parámetro X11Forwarding ....................................................................................................................................................... 79 Aplicando los cambios.................................................................................................................................................................. 80 Probando OpenSSH. ..................................................................................................................................................................... 80 Acceso por shell. ....................................................................................................................................................................... 80 Acceso por SFTP ...................................................................................................................................................................... 80

Página 4

Capítulo 1 Introducción a iptables En este manual se muestran las habituales arquitecturas de redes con firewall y la forma de montar iptables para cada caso, con distintas opciones para cada ejemplo.

¿Qué es un Firewall? Un firewall es un dispositivo que filtra el tráfico entre redes, como mínimo dos. El firewall puede ser un dispositivo físico o un software sobre un sistema operativo. En general debemos verlo como una caja con 2 (dos) o más interfaces de red en la que se establecen una reglas de filtrado con las que se decide si una conexión determinada puede establecerse o no. Incluso puede ir más allá y realizar modificaciones sobre las comunicaciones, como el NAT. Esa sería la definición genérica, hoy en día un firewall es un hardware específico con un sistema operativo o una BIOS que filtra el tráfico TCP/UDP/ICMP/IP y decide si un paquete pasa, se modifica, se convierte o se descarta. Para que un firewall entre redes funcione como tal debe tener al menos dos tarjetas de red. Esta sería la tipología clásica de un firewall:

Figura 1: Esquema de firewall típico entre red local e internet Esquema típico de firewall para proteger una red local conectada a internet a través de un router. El firewall debe colocarse entre el router (con un único cable) y la red local (conectado al switch o al hub de la LAN) Dependiendo de las necesidades de cada red, puede ponerse uno o más firewalls para establecer distintos perímetros de seguridad en torno a un sistema. Es frecuente también que se necesite exponer algún servidor a internet (como es el caso de un servidor web, un servidor de correo, etc.), y en esos casos obviamente en principio se debe aceptar cualquier conexión a ellos. Lo que se recomienda en esa situación es situar ese servidor en lugar aparte de la red, el que denominamos DMZ o zona desmilitarizada. El firewall tiene entonces tres entradas:

Figura 2: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos En la zona desmilitarizada se pueden poner tantos servidores como se necesiten. Con esta arquitectura, permitimos que el servidor sea accesible desde internet de tal forma que si es atacado y se gana acceso a él, la red local sigue protegida por el

Página 5

firewall. Esta estructura de DMZ puede hacerse también con un doble firewall (aunque como se ve se puede usar un único dispositivo con al menos tres interfaces de red). Sería un esquema como este:

Figura 3: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos creado con doble firewall (perímetro) Los firewalls se pueden usar en cualquier red. Es habitual tenerlos como protección de internet en las empresas, aunque ahí también suelen tener una doble función: controlar los accesos externos hacia dentro y también los internos hacia el exterior; esto último se hace con el firewall o frecuentemente con un proxy (que también utilizan reglas, aunque de más alto nivel). También, en empresas de hosting con muchos servidores, lo normal es encontrarnos uno o más firewalls ya sea filtrando toda la instalación o parte de ella:

Figura 4: Esquema de firewall entre redes, en la que solo se filtra y no se hace NAT

Página 6

Sea el tipo de firewall que sea, generalmente no tendrá mas que un conjunto de reglas en las que se examina el origen y destino de los paquetes del protocolo TCP/IP. En cuanto a protocolos es probable que sean capaces de filtrar muchos tipos de ellos, no solo los TCP, también los UDP, los ICMP, los GRE y otros protocolos vinculados a vpns. Este podría ser (en pseudolenguaje) un conjunto de reglas de un firewall del primer gráfico: Política por defecto ACEPTAR. Todo lo que venga de la red local al firewall ACEPTAR Todo lo que venga de la ip de mi casa al puerto tcp 22 ACEPTAR Todo lo que venga de la ip de casa del jefe al puerto tcp 1723 ACEPTAR Todo lo que venga de hora.rediris.es al puerto udo 123 ACEPTAR Todo lo que venga de la red local y vaya al exterior ENMASCARAR Todo lo que venga del exterior al puerto tcp 1 al 1024 DENEGAR Todo lo que venga del exterior al puerto tcp 3389 DENEGAR Todo lo que venga del exterior al puerto udp 1 al 1024 DENEGAR

En definitiva lo que se hace es: • Habilita el acceso a puertos de administración a determinadas IPs privilegiadas • Enmascara el trafico de la red local hacia el exterior (NAT, una petición de un pc de la LAN sale al exterior con la IP pública), para poder salir a internet • Deniega el acceso desde el exterior a puertos de administración y a todo lo que este entre 1 y 1024. Hay dos maneras de implementar un firewall: 1) Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall se acepta y solo se denegará lo que se diga explícitamente. 2) Política por defecto DENEGAR: todo esta denegado, y solo se permitirá pasar por el firewall aquellos que se permita explícitamente. Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya que simplemente nos tenemos que preocupar de proteger aquellos puertos o direcciones que sabemos que nos interesa; el resto no importa tanto y se deja pasar. Por ejemplo, si queremos proteger una máquina linux, podemos hacer un netstat -ln (o netstat -an, o netstat – puta | grep LISTEN), saber que puertos están abiertos, poner reglas para proteger esos puertos y ya está. ¿Para qué vamos a proteger un puerto que realmente nunca se va a abrir? El único problema que podemos tener es que no controlemos que es lo que esta abierto, o que en un momento dado se instale un software nuevo que abra un puerto determinado, o que no sepamos que determinados paquetes ICMP son peligrosos. Si la política por defecto es ACEPTAR y no se protege explícitamente, podemos poner en riesgo la PC o Servidor que queremos proteger. En cambio, si la política por defecto es DENEGAR, a no ser que lo permitamos explícitamente, el firewall se convierte en un auténtico MURO infranqueable. El problema es que es mucho más difícil preparar un firewall así, y hay que tener muy claro como funciona el sistema (sea iptables o el que sea) y que es lo que se tiene que abrir sin caer en la tentación de empezar a meter reglas super-permisivas. Esta configuración de firewall es la recomendada, aunque no es aconsejable usarla si no se domina mínimamente el sistema. Uno de los objetos principales de este documento es mostrar la forma de crear este tipo de firewalls. Importante El orden en el que se ponen las reglas de firewall es determinante. Normalmente cuando hay que decidir que se hace con un paquete se va comparando con cada regla del firewall hasta que se encuentra una que le afecta (match), y se hace lo que dicte esta regla (aceptar o denegar); después de eso NO SE MIRARÁN MÁS REGLAS para ese paquete. ¿Cuál es el peligro? Si ponemos reglas muy permisivas entre las primeras del firewall, puede que las siguientes no se apliquen y no sirvan de nada.

Página 7

¿Qué es iptables? IPtables es un sistema de firewall vinculado al kernel de linux que se ha extendido enormemente a partir del kernel 2.4 de este sistema operativo. Al igual que el anterior sistema ipchains, un firewall de iptables no es como un servidor que lo iniciamos o detenemos o que se pueda caer por un error de programación (aunque ha tenido alguna vulnerabilidad que permite DoS, pero nunca tendrá tanto peligro como las aplicaciones que escuchan en determinado puerto TCP): iptables esta integrado con el kernel, es parte del sistema operativo. ¿Cómo se pone en marcha? Realmente lo que se hace es aplicar reglas. Para ellos se ejecuta el comando iptables, con el que añadimos, borramos, o creamos reglas. Por ello un firewall de iptables no es sino un simple script de shell en el que se van ejecutando las reglas de firewall. Nota Se puede implementar un script de inicio en /etc/rc.d/init.d (ó /etc/init.d) con el que hagamos que iptables se "inicie o pare" como un servicio más. Lo podemos hacer nosotros o es probable que venga en la distribución (como en RedHat por ejemplo). También se pueden salvar las reglas aplicadas con el comando iptables-save en un fichero y gestionar ese fichero con una aplicación o front-end desde la X o desde webmin. Si tenemos una máquina linux con soporte para iptables, tiene reglas aplicadas y empiezan a llegar/salir/pasar paquetes. Por ahora no es necesario que tengamos en cuenta cuantas placas de red hay, que direcciones IP tiene la máquina y olvidemos si el paquete entra o sale. Las reglas de firewall están a nivel de kernel, y al kernel lo que le llega es un paquete y tiene que decidir que hacer con él. El kernel lo que hace es, dependiendo si el paquete es para la propia máquina o para otra máquina, consultar las reglas de firewall y decidir que hacer con el paquete según mande el firewall. Este es el camino que seguiría un paquete en el kernel:

Figura 5: Cuando un paquete u otra comunicación llegan al kernel con iptables se sigue este camino Como se ve en el gráfico, básicamente se mira si el paquete esta destinado a la propia máquina o si va a otra. Para los paquetes (o datagramas, según el protocolo) que van a la propia máquina se aplican las reglas INPUT y OUTPUT, y para filtrar paquetes que van a otras redes o máquinas se aplican simplemente reglas FORWARD. INPUT, OUTPUT y FORWARD son los tres tipos de reglas de filtrado. Antes de aplicar esas reglas es posible aplicar reglas de NAT: estas se usan para hacer redirecciones de puertos o cambios en las IPs de origen y destino. Veremos ejemplos más adelante. E incluso antes de las reglas de NAT se pueden meter reglas de tipo MANGLE, destinadas a modificar los paquetes; son reglas poco conocidas y es probable que no las usen. Por tanto tenemos tres tipos de reglas en iptables: • MANGLE • NAT: reglas PREROUTING, POSTROUTING • FILTER: reglas INPUT, OUTPUT, FORWARD.

Página 8

Creando un firewall con iptables En este tutorial se ha intentado dar una breve introducción sobre lo que es un firewall, sus tipologías básicas y en concreto se presenta el sistema iptables. Ahora veremos configuraciones de firewall con iptables, empezando desde la más básica a las más complejas, en las que se establece la denegación como política por defecto. Nota Se recomienda encarecidamente ir practicando estas reglas en alguna máquina linux disponible, y especialmente hacer uso de la herramienta iptraf para depurar y comprobar el funcionamiento de iptables. Con iptraf podemos comprobar si las conexiones TCP/IP se llegan a establecer o no. Una conexión TCP/IP empieza con el three-way-handshake: • La maquina que desea conectarse a otra envía un paquete con flag SYN • Si la otra maquina acepta, envía un SYN/ACK • Entonces la máquina establece la conexión. Si el firewall esta denegando la conexión, con iptraf veremos que la máquina origen sólo manda paquetes con el flag SYN, y que del otro lado no sale nada. Saber usar iptraf nos ayudará mucho.

Proteger la propia máquina Muy bien, tenemos una máquina linux conectada a internet y queremos protegerla con su propio firewall. Lo único que tenemos que hacer es crear un script de shell en el que se van aplicando las reglas. Los scripts de iptables pueden tener este aspecto: Saludo a la afición (echo) Borrado de las reglas aplicadas actualmente (flush) Aplicación de políticas por defecto para INPUT, OUPUT, FORWARD Listado de reglas iptables.

Ojo con el orden de las reglas #!/bin/sh ## SCRIPT de IPTABLES - ejemplo del manual de iptables ## Ejemplo de script para proteger la propia máquina echo -n Aplicando Reglas de Firewall... ## FLUSH iptables iptables iptables iptables

de reglas –F –X –Z -t nat –F

## Establecemos politica por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT ## Empezamos a filtrar # El localhost se deja (por ejemplo conexiones locales a mysql) /sbin/iptables -A INPUT -i lo -j ACCEPT # A nuestra IP le dejamos todo iptables -A INPUT -s 195.65.34.234 -j ACCEPT

Página 9

# A un colega le dejamos entrar al mysql para que mantenga la BBDD iptables -A INPUT -s 231.45.134.23 -p tcp --dport 3306 -j ACCEPT # A un diseñador le dejamos usar el FTP iptables -A INPUT -s 80.37.45.194 -p tcp -dport 20:21 -j ACCEPT # El puerto 80 de www debe estar abierto, es un servidor web. iptables -A INPUT -p tcp --dport 80 -j ACCEPT # Y el resto, lo cerramos iptables -A INPUT -p tcp --dport iptables -A INPUT -p tcp --dport iptables -A INPUT -p tcp --dport iptables -A INPUT -p tcp --dport

20:21 -j DROP 22 -j DROP 3306 -j DROP 10000 -j DROP

echo " OK . Verifique que lo que se aplica con: iptables -L –n " # Fin del script

Nota Se puede mejorar este script usando variables, se puede poner el comando con el path completo. No olvidarse de ponerle permisos de ejecución con: chmod +x firewall-1.sh ó chmod 750 firewall-1.sh . En fin, ya se ve, un script de los más simples, con unas pocas reglas con las que cerramos puertos al público a los que no tienen porque tener acceso, salvo el 80. Pero cualquiera con algo de ojo se habrá dado cuenta de que ni se filtra el UDP ni el ICMP. Como mencionamos anteriormente, en este tipo de firewall es recomendable hacer un netstat para ver que puertos están en estado de escucha (abiertos), y salvo que un rootkit nos haya modificado los binarios, netstat nos dará la información precisa que necesitamos. Cuidado Aunque nmap también nos muestra los puertos abiertos, dependiendo de cómo lo ejecutemos quizá no nos muestre todos los puertos, ya que suele mirar solo los más conocidos Imaginemos que hemos dado un repaso a nuestro sistema, y ahora si que tenemos mejor identificados los puertos TCP y UDP abiertos. Pero, para estar seguros, al final del script cerraremos el rango de puertos del 1 al 1024, los reservados tanto para TCP como UDP. Reemplazamos el final del script anterior con: # Hasta aquí el script es igual al ejemplo anterior # El puerto 80 de www debe estar abierto, es un servidor web. iptables -A INPUT -p tcp --dport 80 -j ACCEPT # Cerramos rango de los puertos privilegiados. Cuidado con este tipo de # barreras, antes hay que abrir a los que si tienen acceso. iptables -A INPUT -p tcp --dport 1:1024 -j DROP iptables -A INPUT -p udp --dport 1:1024 -j DROP # Y el resto, lo cerramos iptables -A INPUT -p tcp --dport 3306 -j DROP iptables -A INPUT -p tcp --dport 10000 -j DROP iptables -A INPUT -p udp --dport 10000 -j DROP echo " OK . Verifique que lo que se aplica con: iptables -L –n " # Fin del script

Página 10

Nota Si estas reglas de filtrado las esta aplicando en una máquina remota (conectado remotamente) y tiene miedo de perder el control de la máquina remota, pruebe el script en una máquina local y asegúrese de que aplica lo que usted quiere. Funcionar va a funcionar seguro.

Firewall de una LAN con salida a internet Ahora vamos a ver una configuración de firewall iptables para el típico caso de red local que necesita salida a internet.

Figura 6: Esquema de firewall típico entre red local e internet ¿Qué es lo que hace falta? Obviamente, una regla que haga NAT hacia fuera (enmascaramiento en iptables), con lo que se haría dos veces NAT en el firewall y en el router. Entre el router y el firewall lo normal es que haya una red privada (192.168.1.1 y 192.168.1.2 por ejemplo), aunque dependiendo de las necesidades puede que los dos tengan IP pública. El router se supone que hace un NAT completo hacia dentro (quizá salvo puerto 23), o sea que desde el exterior no se llega al router si no que de forma transparente se "choca" contra el firewall. Lo normal en este tipo de firewalls es poner la política por defecto de FORWARD en denegar (DROP), pero eso lo vemos más adelante. Veamos como serían las reglas de este firewall-gateway: #!/bin/sh ## SCRIPT de IPTABLES - ejemplo del manual de iptables ## Ejemplo de script para firewall entre red-local e internet echo -n Aplicando Reglas de Firewall... ## FLUSH iptables iptables iptables iptables

de reglas –F –X –Z -t nat –F

## Establecemos politica por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT ## Empezamos a filtrar ## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN # El localhost se deja (por ejemplo conexiones locales a mysql) /sbin/iptables -A INPUT -i lo -j ACCEPT # Al firewall tenemos acceso desde la red local iptables -A INPUT -s 192.168.10.0/24 -i eth1 -j ACCEPT # Ahora hacemos enmascaramiento de la red local # y activamos el BIT DE FORWARDING (imprescindible!!!!!) iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE # Con esto permitimos hacer forward de paquetes en el firewall, o sea # que otras máquinas puedan salir a traves del firewall.

Página 11

echo 1 > /proc/sys/net/ipv4/ip_forward ## Y ahora cerramos los accesos indeseados del exterior: # Nota: 0.0.0.0/0 significa: cualquier red # Cerramos el rango de puerto bien conocido iptables -A INPUT -s 0.0.0.0/0 -p tcp -dport 1:1024 -j DROP iptables -A INPUT -s 0.0.0.0/0 -p udp -dport 1:1024 -j DROP # Cerramos un puerto de gestión: webmin iptables -A INPUT -s 0.0.0.0/0 -p tcp -dport 10000 -j DROP echo " OK . Verifique que lo que se aplica con: iptables -L -n" # Fin del script

Pero como somos muy malvados queremos que los empleados solamente puedan navegar por internet, denegando el acceso a Kazaa o edonkey. Esta sería una configuración simple pero efectiva. Reemplazamos en el script anterior lo siguiente: # Hasta aquí el script es igual al ejemplo anterior # Al firewall tenemos acceso desde la red local iptables -A INPUT -s 192.168.10.0/24 -i eth1 -j ACCEPT ## Ahora con regla FORWARD filtramos el acceso de la red local ## al exterior. Como se explica antes, a los paquetes que no van dirigidos al ## propio firewall se les aplican reglas de FORWARD # Aceptamos que vayan a puertos 80 iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -p tcp --dport 80 -j ACCEPT # Aceptamos que vayan a puertos https iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -p tcp --dport 443 -j ACCEPT # Aceptamos que consulten los DNS iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -p tcp --dport 53 -j ACCEPT iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -p udp --dport 53 -j ACCEPT # Y denegamos el resto. Si se necesita alguno, ya avisaran iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -j DROP # Ahora hacemos enmascaramiento de la red local # y activamos el BIT DE FORWARDING (imprescindible!!!!!) iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE # De aquí en adelante el script es igual al ejemplo anterior

Supongamos que este firewall tiene alguna función adicional: es un servidor proxy y además es un servidor de correo. Darle funcionalidades de este tipo a un firewall no es recomendable, porque si no se protegen bien esos puertos o si no está actualizado el software pueden entrar en el firewall a base de exploits comprometiendo TODA la red local. De todas formas muchas empresas no se pueden permitir o no quieren tener una máquina para cada cosa, bastante les cuesta a muchas poner un firewall. Por tanto: si se añaden servicios que deben estar abiertos al público en el propio firewall, nos la estamos jugando, y se recomienda pasar el servicio a otra máquina y ponerla en la DMZ. Supongamos también que la empresa tiene empleados que viajan y que se conectan a internet desde su portátil y con una IP dinámica. Supongamos también que el jefe de la empresa quiere acceder a la red local desde casa con una conexión ADSL. Ahora en el firewall deberíamos tener instalado un servidor SMTP, POP3, y un PPTPD. Nuestro script completo quedaría así: #!/bin/sh ## SCRIPT de IPTABLES - ejemplo del manual de iptables ## Ejemplo de script para firewall entre red-local e internet ## con servicios abiertos de puerto 25, 110, y 1723

Página 12

echo -n Aplicando Reglas de Firewall... ## FLUSH de reglas iptables –F iptables –X iptables –Z iptables -t nat –F ## Establecemos politica por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT ## Empezamos a filtrar ## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN # El localhost se deja (por ejemplo conexiones locales a mysql) iptables -A INPUT -i lo -j ACCEPT # Al firewall tenemos acceso desde la red local iptables -A INPUT -s 192.168.10.0/24 -i eth1 -j ACCEPT ## Abrimos el acceso a puertos de correo # Abrimos el puerto 25, hay que configurar bien el relay del servidor SMTP iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport 25 -j ACCEPT # Abrimos el pop3 iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport 110 -j ACCEPT # Y abrimos el puerto pptpd para la ip del adsl de casa del jefe iptables -A INPUT -s 211.45.176.24 -p tcp --dport 1723 -j ACCEPT ## Ahora con regla FORWARD filtramos el acceso de la red local ## al exterior. Como se explica antes, a los paquetes que no van dirigidos al ## propio firewall se les aplican reglas de FORWARD # Aceptamos iptables -A # Aceptamos iptables -A

que vayan a puertos 80 FORWARD -s 192.168.10.0/24 -i eth1 -p tcp --dport 80 -j ACCEPT que vayan a puertos https FORWARD -s 192.168.10.0/24 -i eth1 -p tcp --dport 443 -j ACCEPT

# Aceptamos que consulten los DNS iptables -A FORWARD -s 192.168.10.0/24 iptables -A FORWARD -s 192.168.10.0/24 # Y denegamos el resto. Si se necesita iptables -A FORWARD -s 192.168.10.0/24

-i eth1 -i eth1 alguno, -i eth1

-p -p ya -j

tcp --dport 53 -j ACCEPT udp --dport 53 -j ACCEPT avisaran DROP

# Ahora hacemos enmascaramiento de la red local # y activamos el BIT DE FORWARDING (imprescindible!!!!!) iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE # Con esto permitimos hacer forward de paquetes en el firewall, o sea # que otras máquinas puedan salir a traves del firewall. echo 1 > /proc/sys/net/ipv4/ip_forward ## Y ahora cerramos los accesos indeseados del exterior: # Nota: 0.0.0.0/0 significa: cualquier red # Cerramos el rango de puerto bien conocido iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p tcp -dport 1:1024 -j DROP iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p udp -dport 1:1024 -j DROP # Cerramos un puerto de gestión: webmin iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p tcp --dport 10000 -j DROP

Página 13

# Y cerramos el puerto del servicio PPTPD, solo abierto para el jefe. iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p tcp --dport 1723 -j DROP echo " OK . Verifique que lo que se aplica con: iptables -L -n" # Fin del script

¡Más difícil todavía! Ahora queremos compartir algún servicio pero de un servidor que tenemos dentro de la red local, por ejemplo el IIS de un servidor Windows 2000, y además permitir la gestión remota por terminal server para esta máquina para una empresa externa. En este caso lo que hay que hacer es un redirección de puerto. Antes de iptables esto se podía hacer fácilmente con un servidor como rinet. Rinet lo que hace es simplemente abrir un puerto en el firewall y al conectarse a él te lleva hasta el puerto de otra máquina, como una tubería. Con iptables podemos hacer redirecciones con una ventaja: no perdemos la información de IP origen, cosa que con rinet sí ocurría. En fin, veamos la configuración, con las nuevas reglas de DNAT: #!/bin/sh ## SCRIPT de IPTABLES - ejemplo del manual de iptables ## Ejemplo de script para firewall entre red-local e internet ## con servicios abiertos de puerto 25, 110, y 1723 echo -n Aplicando Reglas de Firewall... ## FLUSH iptables iptables iptables iptables

de reglas –F –X –Z -t nat –F

## Establecemos politica por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT ## Empezamos a filtrar ## REDIRECCIONES # Todo lo que venga por el exterior y vaya al puerto 80 lo redirigimos # a una maquina interna iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.10.12:80 # Los accesos de un ip determinada a Terminal server se redirigen e esa # maquina iptables -t nat -A PREROUTING -s 221.23.124.181 -i eth0 -p tcp --dport 3389 -j DNAT --to 192.168.10.12:3389 ## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN # El localhost se deja (por ejemplo conexiones locales a mysql) iptables -A INPUT -i lo -j ACCEPT # Al firewall tenemos acceso desde la red local iptables -A INPUT -s 192.168.10.0/24 -i eth1 -j ACCEPT ## Abrimos el acceso a puertos de correo # Abrimos el puerto 25, hay que configurar bien el relay del servidor SMTP iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport 25 -j ACCEPT # Abrimos el pop3 iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport 110 -j ACCEPT # Y abrimos el puerto pptpd para la ip del adsl de casa del jefe

Página 14

iptables -A INPUT -s 211.45.176.24 -p tcp --dport 1723 -j ACCEPT ## Ahora con regla FORWARD filtramos el acceso de la red local ## al exterior. Como se explica antes, a los paquetes que no van dirigidos al ## propio firewall se les aplican reglas de FORWARD # Aceptamos iptables -A # Aceptamos iptables -A

que vayan a puertos 80 FORWARD -s 192.168.10.0/24 -i eth1 -p tcp --dport 80 -j ACCEPT que vayan a puertos https FORWARD -s 192.168.10.0/24 -i eth1 -p tcp --dport 443 -j ACCEPT

# Aceptamos que consulten los DNS iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -p tcp --dport 53 -j ACCEPT iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -p udp --dport 53 -j ACCEPT # Y denegamos el resto. Si se necesita alguno, ya avisaran iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -j DROP # Ahora hacemos enmascaramiento de la red local # y activamos el BIT DE FORWARDING (imprescindible!!!!!) iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE # Con esto permitimos hacer forward de paquetes en el firewall, o sea # que otras máquinas puedan salir a traves del firewall. echo 1 > /proc/sys/net/ipv4/ip_forward ## Y ahora cerramos los accesos indeseados del exterior: # Nota: 0.0.0.0/0 significa: cualquier red # Cerramos el rango de puerto bien conocido iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p tcp -dport 1:1024 -j DROP iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p udp -dport 1:1024 -j DROP # Cerramos un puerto de gestión: webmin iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p tcp --dport 10000 -j DROP # Y cerramos el puerto del servicio PPTPD, solo abierto para el jefe. iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p tcp --dport 1723 -j DROP echo " OK . Verifique que lo que se aplica con: iptables -L –n " # Fin del script

Bueno ya tenemos montada la red, pero conviene insistir en que esta última configuración, con las redirecciones y los servicios de correo funcionando en el firewall es bastante insegura. ¿Qué ocurre si hackean el servidor IIS de la red local? Pues que el firewall no sirve de gran cosa, lo poco que podría hacer una vez se ha entrado en la red local es evitar escaneos hacia el exterior desde la máquina atacada, aunque para ello el firewall debiera tener una buena configuración con denegación por defecto. Si necesitamos ese servidor IIS, basta con comprar una placa de red y crear una DMZ.

Firewall de una LAN con salida a internet con DMZ Bueno, esto se va complicando. Imaginemos que tenemos una red parecida a la anterior pero ahora hacemos las cosas bien y colocamos ese servidor IIS en una DMZ:

Página 15

Figura 7: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos. En este tipo de firewall hay que permitir: • Acceso de la red local a internet. • Acceso público al puerto TCP/80 y TCP/443 del servidor de la DMZ • Acceso del servidor de la DMZ a una BBDD de la LAN • Obviamente bloquear el resto de acceso de la DMZ hacia la LAN. ¿Qué tipo de reglas son las que hay que usar para filtrar el tráfico entre la DMZ y la LAN? Solo pueden ser las FORWARD, ya que estamos filtrando entre distintas redes, no son paquetes destinados al propio firewall. #!/bin/sh ## SCRIPT de IPTABLES - ejemplo del manual de iptables ## Ejemplo de script para firewall entre red-local e internet con DMZ echo -n Aplicando Reglas de Firewall... ## FLUSH iptables iptables iptables iptables

de reglas –F –X –Z -t nat –F

## Establecemos politica por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT ## Empezamos a filtrar ## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN # Todo lo que venga por el exterior y vaya al puerto 80 lo redirigimos # a una maquina interna iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.3.2:80 # Los accesos de un ip determinada HTTPS se redirigen e esa # maquina iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to 192.168.3.2:443 # El localhost se deja (por ejemplo conexiones locales a mysql) /sbin/iptables -A INPUT -i lo -j ACCEPT # Al firewall tenemos acceso desde la red local iptables -A INPUT -s 192.168.10.0/24 -i eth1 -j ACCEPT

Página 16

# Ahora hacemos enmascaramiento de la red local y de la DMZ # para que puedan salir haca fuera # y activamos el BIT DE FORWARDING (imprescindible!!!!!) iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -s 192.168.3.0/24 -o eth0 -j MASQUERADE # Con esto permitimos hacer forward de paquetes en el firewall, o sea # que otras máquinas puedan salir a traves del firewall. echo 1 > /proc/sys/net/ipv4/ip_forward ## Permitimos el paso de la DMZ a una BBDD de la LAN: iptables -A FORWARD -s 192.168.3.2 -d 192.168.10.5 -p tcp --dport 5432 -j ACCEPT iptables -A FORWARD -s 192.168.10.5 -d 192.168.3.2 -p tcp --sport 5432 -j ACCEPT ## permitimos abrir el Terminal server de la DMZ desde la LAN iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.3.2 -p tcp --sport 1024:65535 --dport 3389 -j ACCEPT # … hay que hacerlo en uno y otro sentido … iptables -A FORWARD -s 192.168.3.2 -d 192.168.10.0/24 1024:65535 -j ACCEPT

-p

tcp

--sport

3389

--dport

# … por que luego: # Cerramos el acceso de la DMZ a la LAN iptables -A FORWARD -s 192.168.3.0/24 -d 192.168.10.0/24 -j DROP ## Cerramos el acceso de la DMZ al propio firewall iptables -A INPUT -s 192.168.3.0/24 -i eth2 -j DROP ## Y ahora cerramos los accesos indeseados del exterior: # Nota: 0.0.0.0/0 significa: cualquier red # Cerramos el rango de puerto bien conocido iptables -A INPUT -s 0.0.0.0/0 -p tcp -dport 1:1024 -j DROP iptables -A INPUT -s 0.0.0.0/0 -p udp -dport 1:1024 -j DROP # Cerramos un puerto de gestión: webmin iptables -A INPUT -s 0.0.0.0/0 -p tcp -dport 10000 -j DROP echo " OK . Verifique que lo que se aplica con: iptables -L –n " # Fin del script

Si las máquinas de la DMZ tienen una IP pública hay que tener muchísimo cuidado de no permitir el FORWARD por defecto. Si en la DMZ hay IP pública NO ES NECESARIO HACER REDIRECCIONES de puerto, sino que basta con rutar los paquetes para llegar hasta la DMZ. Este tipo de necesidades surgen cuando por ejemplo tenemos dos máquinas con servidor web (un Apache y un IIS); ¿A cuál de las dos le redirigimos el puerto 80? No hay manera de saberlo (con servidores virtuales tampoco), por eso se deben asignar IPs públicas o en su defecto usar puertos distintos. Por tanto hay que proteger convenientemente toda la DMZ. Tampoco haría falta enmascarar la salida hacia el exterior de la DMZ, si tiene una IP pública ya tiene una pata puesta en internet; obviamente hay que decirle al router como llegar hasta esa IP pública. Así podría ser esta red:

Página 17

Figura 8: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos usando IPs públicas Y este podría ser el script para un firewall adecuado: #!/bin/sh ## SCRIPT de IPTABLES - ejemplo del manual de iptables ## Ejemplo de script para firewall entre red-local e internet con DMZ ## pero con IPs públicas. echo -n Aplicando Reglas de Firewall... ## FLUSH iptables iptables iptables iptables

de reglas –F –X –Z -t nat –F

## Establecemos politica por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT ## Empezamos a filtrar ## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN # El localhost se deja (por ejemplo conexiones locales a mysql) /sbin/iptables -A INPUT -i lo -j ACCEPT # Al firewall tenemos acceso desde la red local iptables -A INPUT -s 192.168.10.0/24 -i eth1 -j ACCEPT # Ahora hacemos enmascaramiento de la red local y de la DMZ para que puedan # salir haca fuera y activamos el BIT DE FORWARDING (imprescindible!!!!!) iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE # Con esto permitimos hacer forward de paquetes en el firewall, o sea # que otras máquinas puedan salir a traves del firewall. echo 1 > /proc/sys/net/ipv4/ip_forward ## Permitimos el acceso desde el exterior a los puertos 80 y 443 de DMZ iptables -A FORWARD -d 212.194.89.152 -p tcp -dport 80 -j ACCEPT

Página 18

iptables -A FORWARD -d 212.194.89.152 -p tcp -dport 443 -j ACCEPT iptables -A FORWARD -d 212.194.89.150/30 -j DROP ## Permitimos el paso de la DMZ a una BBDD de la LAN: iptables -A FORWARD -s 212.194.89.152 -d 192.168.10.5 -p tcp --dport 5432 -j ACCEPT # en el otro sentido lo mismo iptables -A FORWARD -s 192.168.10.5 -d 212.194.89.152 -p tcp --sport 5432 -j ACCEPT ## permitimos abrir el Terminal server de la DMZ desde la LAN iptables -A FORWARD -s 192.168.10.0/24 -d 212.194.89.152 -p tcp --sport 1024:65535 -dport 3389 -j ACCEPT # … hay que hacerlo en uno y otro sentido … iptables -A FORWARD -s 212.194.89.152 -d 192.168.10.0/24 -p tcp --sport 3389 --dport 1024:65535 -j ACCEPT # … por que luego: # Cerramos el acceso de la DMZ a la LAN iptables -A FORWARD -s 212.194.89.152 -d 192.168.10.0/24 -j DROP ## Cerramos el acceso de la DMZ al propio firewall iptables -A INPUT -s 212.194.89.152 -i eth2 -j DROP ## Y ahora cerramos los accesos indeseados del exterior: # Cerramos el rango de puerto bien conocido iptables -A INPUT -s 0.0.0.0/0 -p tcp -dport 1:1024 -j DROP iptables -A INPUT -s 0.0.0.0/0 -p udp -dport 1:1024 -j DROP # Cerramos un puerto de gestión: webmin iptables -A INPUT -s 0.0.0.0/0 -p tcp -dport 10000 -j DROP echo " OK . Verifique que lo que se aplica con: iptables -L -n" # Fin del script

¿Por qué hay que explicitar la abertura en uno y otro sentido? Porque la tercera regla cierra todo lo que va de la DMZ a la red local. Para abrir el puerto 3389 de TCP es imprescindible que un paquete de ida sea capaz de llegar hasta la DMZ y que a su vez pueda volver a la LAN. Esto de tener que especificar la abertura en uno y otro sentido será el pan de cada día en un iptables con política DROP por defecto: mejor protección pero más trabajo. ¿Por qué se explicita el puerto de origen/destino 1024:65535 en la primera y segunda regla? Imaginemos que un hacker logra acceso a la máquina de la DMZ. Si no especificamos el puerto de destino en esas dos reglas, el hacker puede abrir CUALQUIER puerto de la LAN siempre que pueda establecer como puerto origen suyo el TCP/3389, cosa fácil para un hacker que sepa algo de C o que tenga el programa pertinente a mano. De todas formas el hacker tendría que saber que existe ese tipo de reglas, si es listo probara con puertos de gestión o con puertos NetBios. El problema es que se deja un vínculo con la LAN bien para administrarlo remotamente o para establecer relaciones de confianza y ahí es donde reside el peligro. En las conexiones "legales" no se usa como puerto origen nada por debajo del 1024; cuando alguien se conecta a otro puerto en su extremo abre un puerto por encima del 1024. Especificándolo en la regla de firewall protegeremos un poco mejor la LAN, aunque los puertos por encima de 1024 estarán en peligro.

Firewall puro y duro entre redes En este caso olvidémonos de redes locales y de NAT. Aquí solo tendremos reglas de filtrado INPUT y FORWARD. Pongamos que tenemos el siguiente escenario:

Página 19

Figura 9: Esquema de firewall entre redes, en la que solo se filtra y no se hace NAT En el firewall debemos indicar una serie de reglas para proteger los equipos que están al otro lado de este dispositivo, todos ellos de la red 211.34.149.0/24. Cada uno de ellos da un servicio determinado, y puede estar gestionado desde distintas IPs, lo que significa que habrá que dar acceso a determinados puertos de gestión (22, 3389, etc.). Este podría ser el aspecto del script del firewall: #!/bin/sh ## SCRIPT de IPTABLES - ejemplo del manual de iptables ## Ejemplo de script para firewall entre redes. echo -n Aplicando Reglas de Firewall... ## FLUSH iptables iptables iptables iptables

de reglas -F -X -Z -t nat –F

## Establecemos politica por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT ## Empezamos a filtrar ## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN # A nuestro firewall tenemos acceso total desde la nuestra IP iptables -A INPUT -s 210.195.55.15 -j ACCEPT # Para el resto no hay acceso al firewall iptables -A INPUT -s 0.0.0.0/0 -j DROP

Página 20

## Ahora podemos ir metiendo las reglas para cada servidor ## Como serán paquetes con destino a otras máquinas se aplica FORWARD ## Servidor WEB 211.34.149.2 # Acceso a puerto 80 iptables -A FORWARD -d 211.34.149.2 -p tcp --dport 80 -j ACCEPT # Acceso a nuestra ip para gestionarlo iptables -A FORWARD -s 210.195.55.15 -d 211.34.149.2 -p tcp --dport 22 -j ACCEPT # El resto, cerrar iptables -A FORWARD -d 211.34.149.2 -j DROP ## Servidor MAIL 211.34.149.3 # Acceso a puerto 25, 110 y 143 iptables -A FORWARD -d 211.34.149.3 -p tcp --dport 25 -j ACCEPT iptables -A FORWARD -d 211.34.149.3 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -d 211.34.149.3 -p tcp --dport 143 -j ACCEPT # Acceso a gestion SNMP iptables -A FORWARD -s 210.195.55.15 -d 211.34.149.3 -p udp --dport 169 -j ACCEPT # Acceso a nuestra ip para gestionarlo iptables -A FORWARD -s 210.195.55.15 -d 211.34.149.3 -p tcp --dport 22 -j ACCEPT # El resto, cerrar iptables -A FORWARD -d 211.34.149.3 -j DROP ## Servidor IRC 211.34.149.4 # Acceso a puertos IRC iptables -A FORWARD -d 211.34.149.4 -p tcp --dport 6666:6668 -j ACCEPT # Acceso a nuestra ip para gestionarlo iptables -A FORWARD -s 210.195.55.15 -d 211.34.149.4 -p tcp --dport 22 -j ACCEPT # El resto, cerrar iptables -A FORWARD -d 211.34.149.4 -j DROP ## Servidor NEWS 211.34.149.5 # Acceso a puerto news iptables -A FORWARD -d 211.34.149.5 -p tcp --dport news -j ACCEPT # Acceso a nuestra ip para gestionarlo iptables -A FORWARD -s 213.194.68.115 -d 211.34.149.5 -p tcp --dport 22 -j ACCEPT # El resto, cerrar iptables -A FORWARD -d 211.34.149.5 -j DROP ## Servidor B2B 211.34.149.6 # Acceso a puerto 443 iptables -A FORWARD -d 211.34.149.6 -p tcp --dport 443 -j ACCEPT # Acceso a una ip para gestionarlo iptables -A FORWARD -s 81.34.129.56 -d 211.34.149.6 -p tcp --dport 3389 -j ACCEPT # El resto, cerrar iptables -A FORWARD -d 211.34.149.6 -j DROP ## Servidor CITRIX 211.34.149.7 # Acceso a puerto 1494 iptables -A FORWARD -d 211.34.149.7 -p tcp --dport 1494 -j ACCEPT

Página 21

# Acceso a una ip para gestionarlo iptables -A FORWARD -s 195.55.234.2 -d 211.34.149.7 -p tcp --dport 3389 -j ACCEPT # acceso a otro puerto quiza de BBDD iptables -A FORWARD -s 195.55.234.2 -d 211.34.149.7 -p tcp --dport 1434 -j ACCEPT iptables -A FORWARD -s 195.55.234.2 -d 211.34.149.7 -p udp --dport 1433 -j ACCEPT # El resto, cerrar iptables -A FORWARD -d 211.34.149.7 -j DROP echo " OK . Verifique que lo que se aplica con: iptables -L -n" # Fin del script

Con esta firewall y sobretodo gracias a las reglas de DROP que metemos tras especificar lo que dejamos abiertos, protegeremos de manera eficaz todos lo puertos abiertos de las máquinas.

Firewall con política por defecto DROP ¿Qué supone el hecho de establecer como política por defecto la denegación? • Se debe explicitar cada conexión permitida en los dos sentidos. • Se debe conocer perfectamente qué debe estar abierto y qué no. • Es mucho más difícil de mantener y si se hace conviene hacerlo desde el principio. • No todo es más trabajo: también supone un firewall mucho más seguro. En el ejemplo de la DMZ ya se presentaba esta situación en las reglas forward de una a otra red. Para ilustrar el DROP por defecto, vamos a mostrar la configuración del ejemplo anterior de firewall entre redes pero con política por defecto DROP. #!/bin/sh ## SCRIPT de IPTABLES - ejemplo del manual de iptables ## Ejemplo de script para firewall entre redes con DROP por defecto echo -n Aplicando Reglas de Firewall... ## FLUSH iptables iptables iptables iptables

de reglas -F -X -Z -t nat –F

## Establecemos politica por defecto: DROP!!! iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP ## Empezamos a filtrar ## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN # A nuestro firewall tenemos acceso total desde la nuestra IP iptables -A INPUT -s 210.195.55.15 -j ACCEPT iptables -A OUTPUT -d 210.195.55.15 -j ACCEPT # Para el resto no hay acceso al firewall # En principio esta de más, pero si rebajamos los permisos temporalmente # nos cubre las espaldas iptables -A INPUT -s 0.0.0.0/0 -j DROP ## Ahora podemos ir metiendo las reglas para cada servidor ## Como serán paquetes con destino a otras máquinas se aplica FORWARD ## Servidor WEB 211.34.149.2 # Acceso a puerto 80 iptables -A FORWARD -d 211.34.149.2 -p tcp --dport 80 -j ACCEPT iptables -A FORWARD -s 211.34.149.2 -p tcp --sport 80 -j ACCEPT

Página 22

# Acceso a nuestra ip para gestionarlo iptables -A FORWARD -s 210.195.55.15 -d 211.34.149.2 -p tcp --dport 22 -j ACCEPT iptables -A FORWARD -s 211.34.149.2 -d 210.195.55.15 -p tcp --sport 22 -j ACCEPT ## Servidor MAIL 211.34.149.3 # Acceso a puerto 25, 110 y 143 iptables -A FORWARD -d 211.34.149.3 iptables -A FORWARD -s 211.34.149.3 iptables -A FORWARD -d 211.34.149.3 iptables -A FORWARD -s 211.34.149.3 iptables -A FORWARD -d 211.34.149.3 iptables -A FORWARD -s 211.34.149.3

-p -p -p -p -p -p

tcp tcp tcp tcp tcp tcp

--dport --sport --dport --sport --dport --sport

25 -j ACCEPT 25 -j ACCEPT 110 -j ACCEPT 110 -j ACCEPT 143 -j ACCEPT 143 -j ACCEPT

# Acceso a gestion SNMP iptables -A FORWARD -s 210.195.55.15 -d 211.34.149.3 -p udp --dport 169 -j ACCEPT iptables -A FORWARD -s 211.34.149.3 -d 210.195.55.15 -p udp --sport 169 -j ACCEPT # Acceso a nuestra ip para gestionarlo iptables -A FORWARD -s 210.195.55.15 -d 211.34.149.3 -p tcp --dport 22 -j ACCEPT iptables -A FORWARD -s 211.34.149.3 -d 210.195.55.15 -p tcp --sport 22 -j ACCEPT ## Servidor IRC 211.34.149.4 # Acceso a puertos IRC iptables -A FORWARD -d 211.34.149.4 -p tcp --dport 6666:6668 -j ACCEPT iptables -A FORWARD -s 211.34.149.4 -p tcp --sport 6666:6668 -j ACCEPT # Acceso a nuestra ip para gestionarlo iptables -A FORWARD -s 210.195.55.15 -d 211.34.149.4 -p tcp --dport 22 -j ACCEPT iptables -A FORWARD -s 211.34.149.4 -d 210.195.55.15 -p tcp --sport 22 -j ACCEPT ## Servidor NEWS 211.34.149.5 # Acceso a puerto news iptables -A FORWARD -d 211.34.149.5 -p tcp --dport news -j ACCEPT iptables -A FORWARD -s 211.34.149.5 -p tcp --sport news -j ACCEPT # Acceso a nuestra ip para gestionarlo iptables -A FORWARD -s 213.194.68.115 -d 211.34.149.5 -p tcp --dport 22 -j ACCEPT iptables -A FORWARD -s 211.34.149.5 -d 213.194.68.115 -p tcp --sport 22 -j ACCEPT # El resto, cerrar iptables -A FORWARD -d 211.34.149.5 -j DROP ## Servidor B2B 211.34.149.6 # Acceso a puerto 443 iptables -A FORWARD -d 211.34.149.6 -p tcp --dport 443 -j ACCEPT iptables -A FORWARD -s 211.34.149.6 -p tcp --sport 443 -j ACCEPT # Acceso a una ip para gestionarlo iptables -A FORWARD -s 81.34.129.56 -d 211.34.149.6 -p tcp --dport 3389 -j ACCEPT iptables -A FORWARD -s 211.34.149.6 -d 81.34.129.56 -p tcp --sport 3389 -j ACCEPT ## Servidor CITRIX 211.34.149.7 # Acceso a puerto 1494 iptables -A FORWARD -d 211.34.149.7 -p tcp --dport 1494 -j ACCEPT iptables -A FORWARD -s 211.34.149.7 -p tcp --sport 1494 -j ACCEPT # Acceso a una ip para gestionarlo iptables -A FORWARD -s 195.55.234.2 -d 211.34.149.7 -p tcp --dport 3389 -j ACCEPT iptables -A FORWARD -s 211.34.149.7 -d 195.55.234.2 -p tcp --sport 3389 -j ACCEPT # acceso a otro puerto quiza de BBDD iptables -A FORWARD -s 195.55.234.2 -d 211.34.149.7 -p tcp --dport 1434 -j ACCEPT

Página 23

iptables -A FORWARD -s 211.34.149.7 -d 195.55.234.2 -p tcp --sport 1434 -j ACCEPT # acceso a otro puerto quiza de BBDD iptables -A FORWARD -s 195.55.234.2 -d 211.34.149.7 -p udp --dport 1433 -j ACCEPT iptables -A FORWARD -s 211.34.149.7 -d 195.55.234.2 -p udp --sport 1433 -j ACCEPT echo " OK . Verifique que lo que se aplica con: iptables -L -n" # Fin del script

Ya esta, hemos levantado un verdadero muro entre internet y el conjunto de servidores que esta tras el firewall. No se puede ni hacer un ping a las máquinas, salvo que se haya dado acceso total a una IP. Si quisieramos dar acceso al ping, pondríamos algo así: Es más llevadero aplicar el DROP por defecto cuando el firewall es para la propia máquina. El primer escenario de esta manual trataba sobre este caso.

Depurar el funcionamiento del firewall Programas útiles: • iptraf Sin duda alguna uno de los programas más prácticos para depurar el firewall es iptables, ya que con el podemos observar si la conexiones se establecen o no; es un programa de consola que es aconsejable controlar ya que muestra en tiempo real el tráfico que atraviesa nuestra máquina con todo lujo de detalles: origen/destino de IPs y puertos, tráfico total o tráfico total según la interfaz de red, etc… Si vemos muchas conexiones simultáneas y nos perdemos, existe la posibilidad de aplicar filtros para captar sólo aquello que nos interesa. • nmap La herramienta para escanear puertos por excelencia. Es una herramienta de consola rápida, efectiva y con multitud de opciones. Podemos usarla desde máquinas ajenas a nuestra red para comprobar si realmente el firewall esta filtrando correctamente y en cierta manera para hacernos una idea de que "visión" pueden tener los hackers de nuestro sistema. • shell En el propio script del firewall podemos añadir algunas opciones para descubrir fallos de sintaxis en las reglas. Claro, imaginemos que tenemos un firewall de 40 líneas y una de ellas falla cuando ejecutamos el script. ¿Cuál es? Es probable que el mensaje de error no aclare lo suficiente, por eso se puede añadir algo así al final de cada regla: ... iptables -A INPUT -s 195.55.234.2 -j ACCEPT && echo " regla-21 ok" iptables -A INPUT -s 213.62.89.145 -j ACCEPT && echo " regla-22 ok" ...

Si la regla se ejecuta bien mostrará el mensajito de ok. Otra opción sería ir eliminando o comentando reglas hasta dar con la regla que tiene la sintaxis incorrecta. Cabe reseñar que puede fallar una regla, pero a partir de ella el resto se ejecutan con normalidad.

Página 24

Capítulo 2 Introducción a Squid Squid es el software para servidor Proxy más popular y extendido entre los sistemas operativos basados sobre UNIX®. Es muy confiable, robusto y versátil. Al ser software libre, además de estar disponible el código fuente, está libre del pago de costosas licencias por uso o con restricción a un uso con determinado número de usuarios. Entre otras cosas, Squid puede hacer Proxy y cache con los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, cache transparente, WWCP, aceleración HTTP, cache de consultas DNS y otras muchas más como filtración de contenido y control de acceso por IP y por usuario.

Software necesario Para poder llevar a cabo los procedimientos descritos en este capítulo y documentos relacionados, usted necesitará tener instalado al menos lo siguiente: • • •

squid-2.4.STABLE1 iptables-1.2.4 kernel-2.4.18-24

•

Todos los parches de seguridad disponibles para la versión de Red Hat que esté utilizando.

Tómese en consideración que, de ser posible, se debe utilizar siempre las versiones estables más recientes de todo el software que vaya a instalar al realizar los procedimientos descritos en este capítulo, a fin de contar con los parches de seguridad necesarios. Ninguna versión de Squid anterior a la 2.4.STABLE1 se considera como apropiada debido a fallas de seguridad de gran importancia, y ningún administrador competente utilizaría una versión inferior a la 2.4.STABLE1. Por favor visite el sito Web de su distribución predilecta para estar al tanto de cualquier aviso de actualizaciones de seguridad. Para Red Hat Linux 7.2, 7.3, 8.0 y 9 hay paquetería de actualización en los siguientes enlaces: • ftp://updates.redhat.com/7.2/en/os/i386/, si su distribución está basada en Red Hat™ 7.2 • ftp://updates.redhat.com/7.3/en/os/i386/, si su distribución está basada en Red Hat™ 7.3 • ftp://updates.redhat.com/8.0/en/os/i386/, si su distribución está basada en Red Hat™ 8.0 • ftp://updates.redhat.com/9/en/os/i386/, si su distribución está basada en Red Hat™ 9

Instalación del software necesario. Regularmente Squid no se instala de manera predeterminada a menos que especifique o contrario durante la instalación del sistema operativo, sin embargo viene incluido en casi todas las distribuciones actuales. El procedimiento de instalación es exactamente el mismo que con cualquier otro software: mount /mnt/cdrom/ rpm -Uvh /mnt/cdrom/*/RPMS/squid-*.i386.rpm eject

Iptables se utilizará para generar las reglas necesarias para el guión de Enmascaramiento de IP. Se instala por defecto en todas las distribuciones actuales que utilicen kernel-2.4.

Página 25

Nota Es importante tener actualizado el kernel por diversas cuestiones de seguridad. No es recomendable utilizar versiones del kernel anteriores a la 2.4.18. Para referencia de cómo instalar paquetes RPM, y cómo actualizar el kernel, vea el LOC 1-2-3, Capítulos 4 y 5.

Antes de continuar Tenga en cuenta que este manual ha sido comprobado varias veces y ha funcionado en todos los casos y si algo no funciona solo significa que usted no lo leyó a detalle y no siguió correctamente las indicaciones. Evite dejar espacios vacíos en lugares indebidos. El siguiente es un ejemplo de como no debe des-comentarse un parámetro. # Opción incorrectamente des-comentada http_access 3128

El siguiente es un ejemplo de como si debe des-comentarse un parámetro. # Opción correctamente des-comentada http_access 3128

Configuración básica. Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá trabajar sobre este utilizando su editor de texto preferido. Existen un gran número de parámetros, de los cuales recomendamos configurar los siguientes: • • • • • • • • • •

http_port cache_mem cache_dir ftp_user ftp_passive Al menos una Lista de Control de Acceso Al menos una Regla de Control de Acceso httpd_accel_host httpd_accel_port httpd_accel_with_proxy

¿Que puerto utilizar para Squid? Parámetro http_port Squid por defecto utilizará el puerto 3128 para atender peticiones, sin embargo se puede especificar que lo haga en cualquier otro puerto o bien que lo haga en varios puertos a la vez. En el caso de un Proxy Transparente, regularmente se utilizará el puerto 80 y se valdrá del re-direccionamiento de peticiones de modo tal que no habrá necesidad alguna de modificar la configuración de los navegadores Web para utilizar el servidor Proxy. Bastará con utilizar como puerta de enlace al servidor. Es importante recordar que los servidores Web, como Apache, también utilizan dicho puerto, por lo que será necesario reconfigurar el servidor Web para utiliza otro puerto disponible, o bien desinstalar o deshabilitar el servidor Web. Hoy en día ya no es del todo práctico el utilizar un Proxy Transparente, a menos que se trate de un servicio de Cyber-Café u oficina pequeña, siendo que uno de los principales problemas con los que lidian los administradores es el mal uso y/o abuso del acceso a Internet por parte del personal. Es por esto que puede resultar más conveniente configurar un servidor Proxy con restricciones por contraseña, lo cual no puede hacerse con un Proxy Transparente, debido a que se requiere un diálogo de nombre de usuario y contraseña. Regularmente algunos programas utilizados comúnmente por los usuarios suelen traer por defecto el puerto 8080 -servicio de cacheo WWW- para utilizarse al configurar que servidor proxy utilizar. Si queremos aprovechar esto en nuestro favor y

Página 26

ahorrarnos el tener que dar explicaciones innecesarias al usuario, podemos especificar que Squid escuche peticiones en dicho puerto también. Siendo así localice la sección de definición de http_port, y especifique: # You may specify multiple socket addresses on multiple lines. # Default: http_port 3128 http_port 3128 http_port 8080

Si desea incrementar la seguridad, puede vincularse el servicio a una IP que sólo se pueda acceder desde la red local. Considerando que el servidor utilizado posee una IP 192.168.1.254, puede hacerse lo siguiente: #You may specify multiple socket addresses on multiple lines. # Default: http_port 3128 http_port 192.168.1.254:3128 http_port 192.168.1.254:8080

¿Cuánta memoria utilizar? Parámetro cache_mem El parámetro cache_mem establece la cantidad ideal de memoria para lo siguiente: • Objetos en tránsito. • Objetos Hot. • Objetos negativamente almacenados en el caché. Los datos de estos objetos se almacenan en bloques de 4 Kb. El parámetro cache_mem especifica un límite máximo en el tamaño total de bloques acomodados, donde los objetos en tránsito tienen mayor prioridad. Sin embargo los objetos Hot y aquellos negativamente almacenados en el caché podrán utilizar la memoria no utilizada hasta que esta sea requerida. De ser necesario, si un objeto en tránsito es mayor a la cantidad de memoria especificada, Squid excederá lo que sea necesario para satisfacer la petición. Por defecto se establecen 8 MB. Puede especificarse una cantidad mayor si así se considera necesario, dependiendo esto de los hábitos de los usuarios o necesidades establecidas por el administrador. Si se posee un servidor con al menos 128 MB de RAM, establezca 16 MB como valor para este parámetro: cache_mem 16 MB

¿Cuanto desea almacenar de Internet en el disco duro? Parámetro cache_dir Este parámetro se utiliza para establecer que tamaño se desea que tenga el cache en el disco duro para Squid. Para entender esto un poco mejor, responda a esta pregunta: ¿Cuánto desea almacenar de Internet en el disco duro? Por defecto Squid utilizará un cache de 100 MB, de modo tal que encontrará la siguiente línea: cache_dir ufs /var/spool/squid 100 16 256

Se puede incrementar el tamaño del cache hasta donde lo desee el administrador. Mientras más grande el cache, más objetos de almacenarán en éste y por lo tanto se utilizará menos el ancho de banda. La siguiente línea establece un cache de 700 MB: cache_dir ufs /var/spool/squid 700 16 256

Los números 16 y 256 significan que el directorio del cache contendrá 16 subdirectorios con 256 niveles cada uno. No modifique esto números, no hay necesidad de hacerlo. Nota Es muy importante considerar que si se especifica un determinado tamaño de cache y este excede al espacio real disponible en el disco duro, Squid se bloqueará inevitablemente. Sea cauteloso con el tamaño de cache especificado.

Página 27

Aviso de problemas con la cache - Parámetro cache_mgr. Por defecto, si algo ocurre con el Cache, como por ejemplo que muera el proceso, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente. cache_mgr [email protected]

Acceso FTP anónimo a Servidores - Parámetro ftp_user Al acceder a un servidor FTP de manera anónima, por defecto Squid enviará como contraseña Squid@. Si se desea que el acceso anónimo a los servidores FTP sea más informativo, o bien si se desea acceder a servidores FTP que validan la autenticidad de la dirección de correo especificada como contraseña, puede especificarse la dirección de correo electrónico que uno considere pertinente. ftp_user [email protected]

Acceso FTP pasivo a traves de un Firewall - Parámetro ftp_passive Si se tiene un muro contrafuegos que no permite acceder a servidores FTP más que de modo pasivo, debe habilitarse ftp_passive con el valor on. ftp_passive on

Control de acceso Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas maquinas en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid. Procedamos a entender como definir unas y otras.

Control de acceso - Listas Regularmente una lista de control de acceso se establece siguiendo la siguiente sintaxis: acl [nombre de la lista] src [lo que compone a la lista]

Si uno desea establecer una lista de control de acceso que defina sin mayor trabajo adicional a toda la red local definiendo la IP que corresponde a la red y la máscara de la sub-red. Por ejemplo, si se tienen una red donde las máquinas tienen direcciones IP 192.168.1.n con máscara de sub-red 255.255.255.0, podemos utilizar lo siguiente: acl miredlocal src 192.168.1.0/255.255.255.0

También puede definirse una Lista de Control de Acceso invocando un fichero localizado en cualquier parte del disco duro, y en el cual se en cuenta una lista de direcciones IP. Ejemplo: acl permitidos src "/etc/squid/permitidos"

El fichero /etc/squid/permitidos contendría algo como siguiente: 192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.15 192.168.1.16 192.168.1.20 192.168.1.40

Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el fichero /etc/squid/permitidos.

Página 28

Control de acceso - Reglas Estas definen si se permite o no el acceso a Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda: # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

La sintaxis básica es la siguiente: http_access [deny o allow] [lista de control de acceso]

En el siguiente ejemplo consideramos una regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada “permitidos”: http_access allow permitidos

También pueden definirse reglas valiéndose de la expresión “!”, la cual significa excepción. Pueden definirse, por ejemplo, dos listas de control de acceso, una denominada lista1 y otra denominada lista2, en la misma regla de control de acceso, en donde se asigna una expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo que comprenda lista1 excepto aquello que comprenda lista2: http_access allow lista1 !lista2

Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso, y otro grupo dentro de la misma red al que se debe denegar el acceso.

Aplicando Listas y Reglas de control de acceso. Una vez comprendido el funcionamiento de la Listas y las Reglas de Control de Acceso, procederemos a determinar cuales utilizar para nuestra configuración. Caso 1 Considerando como ejemplo que se dispone de una red 192.168.1.0/255.255.255.0, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso: acl todalared src 192.168.1.0/255.255.255.0

Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo: # Recommended minimum configuration: acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl todalared src 192.168.1.0/255.255.255.0

A continuación procedemos a aplicar la regla de control de acceso: http_access allow todalared

Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo: # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access allow localhost http_access allow todalared http_access deny all

Página 29

La regla http_access allow todalared permite el acceso a Squid a la Lista de Control de Acceso denominada todalared, la cual está conformada por 192.168.1.0/255.255.255.0. Esto significa que cualquier máquina desde 192.168.1.1 hasta 192.168.1.254 podrá acceder a Squid. Caso 2 Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un fichero que contenga dicha lista. Genere el fichero /etc/squid/lista, dentro del cual se incluirán solo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo: 192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.15 192.168.1.16 192.168.1.20 192.168.1.40

Denominaremos a esta lista de control de acceso como redlocal: acl redlocal src "/etc/squid/lista"

Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo: # Recommended minimum configuration: acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl redlocal src "/etc/squid/lista"

A continuación procedemos a aplicar la regla de control de acceso: http_access allow redlocal

Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo: # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access allow localhost http_access allow redlocal http_access deny all

La regla http_access allow redlocal permite el acceso a Squid a la Lista de Control de Acceso denominada redlocal, la cual está conformada por las direcciones IP especificadas en el fichero /etc/squid/lista. Ésto significa que cualquier máquina no incluida en /etc/squid/lista no tendrá acceso a Squid.

Cache con aceleración. Cuando un usuario hace petición hacia un objeto en Internet, este es almacenado en el cache de Squid. Si otro usuario hace petición hacia el mismo objeto, y este no ha sufrido modificación alguna desde que lo accedió el usuario anterior, Squid mostrará el que ya se encuentra en el cache en lugar de volver a descargarlo desde Internet. Esta función permite navegar rápidamente cuando los objetos ya están en el cache de Squid y además optimiza enormemente la utilización del ancho de banda. En la sección HTTPD-ACCELERATOR OPTIONS deben habilitarse los siguientes parámetros: httpd_accel_host virtual httpd_accel_port 0 httpd_accel_with_proxy on

Página 30

Si se trata de un Proxy transparente deben utilizarse con las siguientes opciones, considerando que se hará uso del cache de un servidor web (Apache) como auxiliar: # Debe especificarse la IP de cualquier servidor Web en la red local # o bien virtual httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on

La configuración de Squid como proxy trasparente solo requiere complementarse utilizando una regla de iptables que se encargará de redireccionar peticiones haciéndolas pasar por el puerto 8080. /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Por defecto el parámetro httpd_accel_with_proxy viene con el valor off, es importante no olvidar cambiar este valor por on.

Estableciendo el idioma por defecto. Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un momento dado. Dichas traducciones se pueden encontrar en /usr/lib/squid/errors/. Para poder hacer uso de las páginas de error traducidas al español, es necesario cambiar un enlace simbólico localizado en /etc/squid/errors para que apunte hacia /usr/lib/squid/errors/Spanish en lugar de hacerlo hacia /usr/lib/squid/errors/English. Elimine primero el enlace simbólico actual: rm -f /etc/squid/errors

Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros correspondientes a los errores traducidos al español. Para RedHat 7.x y 8.0 ln -s /usr/lib/squid/errors/Spanish /etc/squid/errors

Para RedHat 7.x y 8.0 ln -s /usr/share/squid/errors/Spanish /etc/squid/errors

Iniciando, reiniciando y añadiendo el servicio al arranque del sistema. Una vez terminada la configuración, ejecute el siguiente comando para iniciar por primera vez Squid: /etc/rc.d/init.d/squid start

ó

service squid start

Si necesita reiniciar para probar cambios hechos en la configuración, ejecute lo siguiente: /etc/rc.d/init.d/squid restart

ó

service squid restart

Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, ejecute lo siguiente: /sbin/chkconfig --level 345 squid on

Lo anterior habilitará a Squid en los niveles de corrida 3, 4 y 5.

Página 31

Cuidado Usted NO tiene porque editar cosa alguna en /etc/rc.d/rc.local o /etc/inittab para que Squid -así como cualquier otro servicio- inicie en el arranque del sistema.

Ajustes para el Firewall o script de Enmascaramiento de IP. A continuación comentaremos algunos ajustes que pueden añadirse o editarse en el script del firewall, como el generado por herramientas como Firestarer (http://firestarter.sourceforge.net), o bien un simple script de Enmascaramiento de IP. Sugerimos utilizar Firestarer debido a que permite configurar tanto el enmascaramiento de IP como el firewall y la importancia que tiene la presencia de éste último en un servidor que sirve como puerta de enlace para la red local.

Use Iptables en lugar de ipchains. Desde el kernel 2.4, GNU/Linux utiliza Netfilter, el cual se configura a través de iptables. La sintaxis cambia con respecto a ipchains, y a fin de permitir a los administradores darse tiempo de adaptarse, distribuciones como Red Hat ™ incluyeron soporte para ipchains a manera de aplicación de legado. Pudiendo utilizarse iptables no tiene sentido mantener instalado ipchains, que aún es utilizado por defecto en Red Hat Linux ™ 7.1 y 7.2. Se recomienda desinstalar ipchains y los paquetes que dependan de este. Es importante utilizar la más reciente versión de iptables para la distribución utilizada. Ninguna versión de iptables anterior a la 1.2.4 se considera como apropiada debido a fallas de seguridad de gran importancia, y ningún administrador competente utilizaría una versión inferior a la 1.2.4. Por favor visite el sito Web de su distribución predilecta para estar al tanto de cualquier aviso de actualizaciones de seguridad. Ejemplo: para Red Hat Linux 7.2, 7.3. 8.0 y 9 hay paquetes de actualización en los siguientes enlaces: • • • •

ftp://updates.redhat.com/7.2/en/os/i386/, si su distribución es Red Hat™ Linux 7.2 ftp://updates.redhat.com/7.3/en/os/i386/, si su distribución es Red Hat™ Linux 7.3 ftp://updates.redhat.com/8.0/en/os/i386/, si su distribución es Red Hat™ Linux 8.0 ftp://updates.redhat.com/9/en/os/i386/, si su distribución es Red Hat™ Linux 9

Antes de desinstalar ipchains, que se instala de modo pre-determinado en Red Hat Linux 7.x, primero debe eliminarse cualquier regla que pudiese existir. /sbin/ipchains -X /sbin/ipchains -F /sbin/ipchains -Z

A continuación debe removerse el módulo de ipchains para permitir la carga del módulo ip_tables. /sbin/rmmod ipchains /sbin/modprobe ip_tables

Para terminar, si utiliza Red Hat Linux 7.2 y 7.3, se debe desinstalar ipchains y toda la paquetería que dependa de éste. rpm -e ipchains lokkit gnome-lokkit firewall-config

Esto ajustes deben poder permitir utilizar iptables en lugar de ipchains sin mayor problema.

Re-direccionamiento de peticiones. En un momento dado se requerirá tener salida transparente hacia Internet para ciertos servicios, pero al mismo tiempo se necesitará re-direccionar peticiones hacia servicio WWW, WWW SSL, FTP, GOPHER o WAIS hacia el el puerto donde escucha peticiones Squid (8080), de modo que no haya salida alguna hacia alguno de estos protocolos sin que ésta pase antes por Squid.

Página 32

El re-direccionamiento lo hacemos a través de iptables. Considerando para este ejemplo que la red local se accede a través de una interfaz eht0, el siguiente esquema ejemplifica un re-direccionamiento: /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Lo anterior hace que cualquier petición hacia el puerto 80 (servicio HTTP) hecha desde la red local hacia el exterior, se redireccionará hacia el puerto 8080 del servidor.

Script ejemplo de Enmascaramiento de IP con iptables. El guión que mostramos en la tabla a continuación considera que se dispone de dos interfaces: eth0 y eth1. Para nuestro ejemplo la red local se accede por la interfaz eth0 y la salida hacia Internet de hace por la interfaz eth1. Utilice Firestarer para configurar el enmascaramiento y muro contrafuegos siempre que sea posible. Cuidado Este script NO es sustituto para un script de firewall.

#!/bin/sh # cargamos los módulos del kernel necesarios: modprobe ip_conntrack modprobe ip_conntrack_ftp modprobe ip_conntrack_irc modprobe ipt_REJECT modprobe ipt_REDIRECT modprobe ipt_TOS modprobe ipt_MASQUERADE modprobe ipt_LOG modprobe iptable_mangle modprobe iptable_nat modprobe ip_nat_ftp modprobe ip_nat_irc # Habilitamos el reenvío de direcciones IP if [ -e /proc/sys/net/ipv4/ip_forward ]; then echo 0 > /proc/sys/net/ipv4/ip_forward fi # Estableciendo política de reenvío del enmascaramiento iptables -t filter -P FORWARD DROP # Reenvío de trafico intento-externo y externo-interno iptables -t filter -A FORWARD -d 0/0 -s 192.168.1.0/255.255.255.0 -o eth0 -j ACCEPT iptables -t filter -A FORWARD -d 192.168.1.0/255.255.255.0 -j ACCEPT # Enmascaramiento de todo el trafico saliente # NOTA: la salida hacia Internet es por la interfaz eth0 iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE # No enmascararemos tráfico externo iptables -t nat -A POSTROUTING -o eth1 -d 0/0 -j ACCEPT # Permitir al tráfico iptables -t filter -A iptables -t filter -A iptables -t filter -A

de la red interna ir a donde sea INPUT -s 192.168.1.0/255.255.255.0 T -d 0/0 -j ACCEPT OUTPUT -s 192.168.1.0/255.255.255.0 -d 0/0 -j ACCEPT OUTPUT -p icmp -s 192.168.1.0/255.255.255.0 -d 0/0 -j ACCEPT

# Re-direccionamiento hacia el puerto 8080 (donde Squid escucha peticiones) # para cualquier petición originada desde la red local hacia servicios que # utilicen protocolo http, https y ftp.

Página 33

# Pueden añadirse más re-direccionamientos a discreción del administrador. # NOTA 1: la red local se accede con la interfaz eth1 # HTTP iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Página 34

Capítulo 3 Introducción a FTP FTP (File Transfer Protocol; Protocolo de Transferencia de Archivos) existe en Internet desde 1971. De forma extraordinaria, el protocolo ha permanecido con muy pocos cambios hasta hoy. Por otro lado, los clientes y los servidores son constantemente mejorados y refinados. Aquí se estudia la instalación y configuración de un servidor particularmente refinado, el servidor de FTP de la Universidad de Washington, más conocido como wu-ftpd. La mayoría de las distribuciones de Linux vienen con wu-ftpd como servidor de FTP por defecto. Muchos sitios comerciales no Linux también utilizan wu-ftpd en lugar del servidor que viene con sus variantes de UNIX por las mismas razones que wu-ftpd es el servidor que se ha elegido para Linux: su estabilidad, flexibilidad y seguridad. En lo que sigue analizaremos cómo bajarse la versión última de wu-ftpd y compilarla e instalarla. También mostraremos cómo configurar su acceso privado, así como el acceso anónimo. Y por último, mostraremos cómo configurar dominios virtuales con wu-ftpd.

El ABC de FTP El acto de transferir un archivo de un equipo a otro puede parecer trivial, pero en realidad no lo es. Primero describiremos paso a paso los detalles de la interacción cliente/servidor de FTP. Aunque esta información no es crucial para ser capaz de conseguir configurar y arrancar un servidor FTP, es importante cuando necesite considerar temas de seguridad así como cuando se tengan problemas.

La relación cliente/servidor Cuando un cliente FTP se quiere conectar con un servidor FTP, elige un puerto alto al azar (un puerto con un número mayor que 1024) como su origen y el puerto 21 como destino en el servidor FTP (el puerto 21 es el puerto FTP definido como estándar). Una vez establecida la conexión, el cliente puede entrar e introducir comandos para navegar por los directorios del servidor FTP. Cuando el cliente hace la petición de una transferencia de un archivo, el cliente reserva otro puerto alto aleatorio y empieza a escuchar por él. Envía su número de puerto nuevo al servidor FTP sobre la conexión existente. El servidor FTP toma ese número de puerto e inicializa una conexión nueva desde uno de sus puertos altos aleatorios a número de puerto que le proporciona el cliente. La conexión original se mantiene abierta para que el cliente y el servidor puedan seguir enviándose información adicional «fuera» del mensaje (por ejemplo, interrumpir la transferencia). Este diseño, concebido a principios de los años setenta, se asumió como algo razonable durante un largo período de tiempo en Internet: los usuarios de Internet son un grupo de amigos que se conocen bien. Se estaba de algún modo protegido por el hecho de que el núcleo de Internet lo fundó la NSF (Nacional Science Fundation-Fundación de ciencia nacional), y no se permitía dentro a organizaciones comerciales a menos que trabajaran en conjunto con el instituto de investigación. Los laboratorios de investigación académicos y gubernamentales formaban la mayoría de los usuarios. Alrededor de 1990-1991, la NSF dejo de correr con los gastos del núcleo de Internet e Internet se hizo comercial. Al principio, no era muy grande. Entonces llegó la World Wide Web, la Telaraña Mundial (WWW) y la población de la Red explotó (con los problemas de seguridad). Muchos sitios empezaron a usar firewalls para proteger sus redes internas del «Gran Malvado Internet». Sin embargo, los firewalls consideran que las conexiones arbitrarias realizadas por los puertos altos desde Internet a los puertos altos de la red interna son una cosa mala. Como resultado, muchos firewalls implementan proxies a nivel de aplicación para FTP, los cuales siguen la pista a las peticiones FTP y abren los puertos altos cuando se necesita recibir datos de un sitio remoto. Naturalmente, no todos los firewalls son tan elegantes. Muchos sitios confían en los filtrados de paquetes de los firewalls, los cuales no entienden los datos que pasan a través de ellos, pero saben que los datos que se envían a un puerto alto son malos y así los devuelven. Este tipo de firewall no permite trabajar a FTP porque FTP confía en ser capaz de abrir una conexión de vuelta al cliente por un puerto alto. Ahora volvamos atrás en el tiempo y pensemos en cuando FTP fue creado y el ancho de banda era un lujo. Cuando alguien quería conseguir una transferencia de un archivo de una máquina A a una máquina B mientras tiene una sesión con la máquina C, el proceso de transferencia del archivo de la máquina A a la máquina C y desde C hasta la máquina B consumía un montón de ancho de banda. Así que los diseñadores del protocolo FTP dieron con una solución: hacer posible que alguien situado en la

Página 35

máquina C transfiriera un archivo desde la máquina A hasta la B directamente. Esto se realizó gracias a una transferencia pasiva. Las transferencias pasivas se consiguen iniciando la conexión para transferencia de datos desde el lado del cliente en lugar de ser el servidor quien inicia la conexión. Desde el punto de vista de los firewalls, esto permite que los clientes continúen seguros detrás del firewall sin la necesidad de reglas complejas que permitan la conexión de entrada.

¿Cómo conseguir la última versión de wu-ftpd? Como el software de otros servidores, wu-ftpd experimenta actualizaciones y mejoras de sus componentes básicos. Estas actualizaciones están disponibles (vía FTP, naturalmente) en ftp://ftp.wu-ftpd.org. El sitio Web, http://www.wu-ftpd.org, es también un buen lugar para conseguir información del estado del demonio wu-ftpd. Cuando se escribió este texto, la versión última de wu-ftpd era la 2.5.0; sin embargo, muchos CD-ROM se distribuyen con la 2.4.2VR17. Se recomienda la mejora, puesto que el grupo de desarrollo de wu-ftpd no soporta las versiones anteriores. La mejora es especialmente importante si hereda un sistema Linux (o cualquier otro sistema UNIX) que ejecute cualquier versión de wu-ftpd anterior al parche VR14, porque tiene un problema de seguridad ampliamente conocido que los «chicos de los scripts» han usado para romper sitios. Puede bajarse la Versión 2.5.0 desde ftp://ftp.wu-ftpd.org/pub/wu-ftpd/wu/ftpd-2.5.0.tar.gz. Una vez que se baje el paquete, necesitará realizar un tar sobre él con el siguiente comando: # tar -xvzf wu-ftpd-2.5.0.tar.gz

Esto creará un subdirectorio llamado wu-ftpd-2.5.0 a partir del directorio actual, donde se desempaquetarán todos los archivos de código fuente. Por motivos de consistencia, debería desempaquetar esto y cualquier otro software que compile en el directorio /usr/local/src.

Lectura de los README Encontrará que wu-ftpd viene con varios archivos de documentación en formato texto. Uno de estos archivos incluye el procedimiento de compilación de wu-ftpd en varias plataformas (por si está interesado en hacerlo). Tómese algunos minutos para leer estos documentos. En esta versión, y en las futuras versiones, la documentación que viene con el paquete contiene mucha información para encontrar recursos de ayuda online, así como notas sobre el paquete para los desarrolladores que quieran saber más. También es útil leer la documentación que viene con el paquete antes de entrar en cualquier foro de discusión con preguntas.

Compilación e instalación de wu-ftpd Desde el subdirectorio en el que haya desempaquetado wu-ftpd, necesita escribir # ./build 1nx

y ya está hecho. El script lleva a cabo el proceso de compilación y verificación por usted. Al final del proceso de compilación, debería ver algo parecido a esto: Executables are in bin directory: text data bss dec 125940 15156 72608 213704 5311 448 36 5795 4959 364 36 5359 5311 448 36 5795 2154 244 28 3026 Done

hex 342c8 16a3 14ef 16a3 bd2

filename bin/ftpd bin/ftpcount bin/ftpshut bin/ftpwho bin/ckcontig

Si hay una configuración existente, podría querer realizar una copia de los archivos de configuración para que el proceso de instalación no los sobrescriba. Los archivos que necesita guardar son éstos: /etc/ftpaccess /etc/ftpgroups /etc/ftphosts

Página 36

/etc/ftpusers

Una vez guardados, está todo preparado para realizar la instalación. Si aún no es el usuario root, use el comando su para convertirse en root. Entonces introduzca el comando # ./build install

Esto provocará que todos los binarios y las páginas man se instalen en sus localizaciones adecuadas. Con los binarios en su sitio, estamos preparados para editar el archivo /etc/services para que el sistema sea capaz de unir los números de puerto de FTP al servicio listado en /etc/inetd.conf. Asegúrese de que /etc/services contiene las dos líneas siguientes: ftp-data ftp

20/tcp 21/tcp

Ahora puede editar el archivo /etc/inetd.conf para que el sistema lance automáticamente el servidor de FTP cuando alguien trate de conectarse a él. Para hacer los cambios, abra el archivo /etc/inetd.conf con un editor de textos. En la parte superior del archivo, debería encontrar una línea que empieza con «ftp». Si no encuentra esa línea, entonces necesitará añadirla. Puede añadir esta línea en cualquier posición del archivo. Asegúrese de que la línea ftp del archivo /etc/inetd.conf dice lo siguiente: ftp

stream tcp

nowait

root

/usr/sbin/tcpd

in.ftpd -l -a

El archivo /etc/inetd.conf se gestiona con el programa inetd, el cual actúa como una especie de «super-servidor», que escucha las peticiones de red en lugar de otros servidores de aplicación e inicia las aplicaciones servidores cuando detecta una petición de conexión para ellas. Si el archivo de configuración /etc/inetd.conf cambia, necesita enviarle al proceso inetd una señal indicándole que debe recargar su archivo de configuración. Esto se hace de una de estas dos formas: 1. Ejecutando el comando siguiente: kill -l `ps auxw

| grep inetd | grep -v grep | awk '{ print $2}' `

2. Mire si su distribución guarda el ID del proceso en el archivo /var/run/inetd.pid. Si es así, puede usar: kill -1 'cat /var/run/inetd.pid'

Y debería ser capaz de realizar ftp sobre su propio sistema. No se preocupe si no puede entrar en él todavía (explicaremos algunos detalles más después), pero al menos debería ser capaz de conseguir el símbolo del sistema FTP.

Configuración de wu-ftpd El paquete wu-ftpd viene con varios archivos de configuración de ejemplo que son fáciles de modificar e instalar en su servidor FTP. Más tarde, presentaremos algunas configuraciones predefinidas por si tiene necesidad de un inicio rápido. Esta sección se enfoca en los detalles que ofrece wu-ftpd. Encontrará una herramienta de referencia práctica en lugar de un tutorial, pero al menos echarle un vistazo está justificado.

Control de acceso a través del archivo /etc/ftpaccess El archivo /etc/ftpaccess contiene cinco tipos de comandos: • Control de acceso. • Información automática para clientes. • Configuración de entrada. • Permisos. • Controles de tipo de archivo y directorio. Examinaremos cada comando específico integrado en cada uno de los grupos.

Página 37

Control de acceso Controlar quién entra y quién no en el servidor FTP es un aspecto crucial de la gestión de un servidor. Los comandos siguientes le permiten hacer eso. CLASS

El comando class define una clase nueva de usuarios en su sistema. No garantiza ni concede ningún derecho en especial, pero la definición de una clase es necesaria para referenciar un grupo de usuarios en los comandos que se estudian más tarde. El formato del comando class es class

nombre-clase tipo

dirección...

Donde nombre-clase es el nombre de la clase nueva que defina. Tipo es uno de estos tres valores: anonymous, real o guest. • Los usuarios anonymous (anónimos) son justamente eso: usuarios que acceden al servidor sin tener ningún tipo de permiso explícito. Note que por definir una clase que permita usuarios anónimos, no está configurando un FTP anónimo. • Los usuarios real (reales) deben tener una cuenta y una shell válida en el sistema. En el caso de FTP, definimos una shell válida como cualquier shell que aparezca en el archivo /etc/shells. • Los usuarios guest (invitados) son aquellos que no tienen una cuenta real en el servidor, pero están incluidos explícitamente en el grupo de invitados (se explica más tarde). Por último, dirección... es la lista de direcciones IP que se originan desde la clase definida. El asterisco (*) es un metacarácter que indica que todas las direcciones IP son válidas para la clase definida. class

mi-clase

anonymous

10.10.*

define la clase mi-clase, la cual consta únicamente de usuarios anónimos cuyas direcciones IP comienzan por 10.10. Podemos tener tantas entradas de clase como queramos. AUTOGROUP

El comando autogroup se usa para indicar a qué grupos de usuarios anónimos de UNIX se pretende cuando se entra en el servidor FTP. Mediante la configuración del grupo al que pertenece, puede retener un control ajustado sobre qué archivos puede o no puede tener acceso. El formato del comando autogroup es autogroup

nombre-grupo clases...

donde nombre-grupo es el nombre del grupo al que quiere que pertenezcan los usuarios anónimos (observe que el nombre-grupo se debería corresponder con una entrada del archivo /etc/group) y clases... es una lista de clases a las que quiera afectar con este comando. Por ejemplo, si define tres clases, class a anonymous,real class b anonymous,real,guest class c anonyrnous,real

10.10.* 192.168.5.* 192.168.7.10 192.168.7.11 192.168.7.12

puede especificar una clase autogroup como ésta: autogroup

anonftp a b

Ahora alguien de las clases a o b que entre como anónimo tiene que trabajar dentro de los

Página 38

límites del grupo anonftp. DENY

El comando deny le permite bloquear el acceso a su sistema basándose en la dirección IP de origen o en el nombre de máquina. El formato del comando deny es de esta forma: deny

direcciones

archivo_mensaje

donde dirección es la dirección IP y el archivo_mensaje es el nombre de archivo del mensaje que quiera devolver cuando traten de conectarle. Por ejemplo, el comando deny

192.168.66.7 /home/ftp/no_evil_crackers

debería provocar que los contenidos del archivo /home/ftp/no_evil_crackers se enviarán a cualquier usuario que trate de entrar en el servidor desde la dirección IP 192.168.66.7. Nota Debido a que la resolución de nombres inversa es poco fiable, se recomienda que use sólo direcciones IP. GUESTGROUP

El comando guestgroup es útil cuando tiene usuarios reales, pero que desea que sus privilegios se vean recortados de forma similar a los usuarios anónimos. El formato del comando es: guestgroup

nombre-grupo...

donde nombre-grupo es el nombre de uno o más grupos (tomado del /etc/group) que quiera restringir. Para restringir usuarios de esta forma, además de la entrada en el archivo /etc/ft-paccess, necesita cambiar el formato de cada entrada de usuario del /etc/passwd. El formato nuevo debería tener su directorio /home situado entre los caracteres (/./). Antes de la barra debería estar el directorio raíz efectivo y después de la barra debería estar el directorio home del usuario efectivo. Por ejemplo, la entrada cor:ilhsvmt1m8wh:256:1024:Carlos Rodriguez:/ftp/./cor:/bin/ftponly

significa que /ftp es el nuevo directorio raíz relativo del usuario. Esto debería prevenir que el usuario vel el directorio /home real, o cualquier otro directorio de path. Debido a esto, necesita situar un directorio bin, etc y lib en /ftp donde existan las bibliotecas y binarios que permitan funcionar a ftp. Este aspecto es idéntico a la configuración de un usuario anónimo, el cual se explica más tarde. Relativo a /ftp habrá un subdirectorio llamado cor, el cual será el directorio home de entrada vía FTP. Debido a que /bin/ftponly no es una shell real, no podría realizar un telnet al sistema. Sin embargo, asegúrese de que /bin/ftponly se lista en el archivo /etc/shells. LIMIT

El comando limit le permite controlar el número máximo de usuarios que pueden entrar en el sistema mediante FTP por clase y día de la semana. El formato del comando limit es limit clase n fecha archivo-mensaje

donde clase es el nombre de la clase afectada, n es el número máximo, fecha es el día y la hora que se pennite entrar a los usuarios y archivo-mensaje es el archivo que se muestra a los usuarios que no puedan entrar. El formato de la entrada fecha es un poco difícil. El parámetro es de la forma de una cadena

Página 39

de texto delimitada por comas, donde cada opción es para un día separado. De domingo a sábado toman la forma de Su, Mo, Tu, We, Th, Fr y Sa, respectivamente, y se pueden indicar todos los días de la semana con Wk. La hora va en formato militar, sin un símbolo de dos puntos separando horas y minutos. Un rango se especifica con el carácter guión (-). Por ejemplo, para limitar a la clase anonpeoples a un máximo de 25 de lunes a jueves durante todo el día y los viernes hasta las 7 de la tarde, debería usar la línea limit anonpeoples 25 MoTuWeTh,FrOOOO-1900 /home/ftp/.message.too_many

donde los contenidos del archivo /home/ftp/.message.too_many se devuelven al usuario si se excede el máximo.

Nota El soporte del comando limit es para aquellos servidores que tengan limitaciones en términos de ancho de banda disponible, o para servidores que necesiten estar disponibles para otras tareas durante ciertos momentos. Por ejemplo, un servidor FTP que hace disponibles hojas de errores de productos debería ser accesible por los clientes durante las horas normales de oficina. Sólo durante las horas de la noche, cuando el tráfico de negocios cae hasta niveles aceptables, puede considerarse usar la máquina como colección de bandas discográficas. El comando limit le permite llevar a cabo este tipo de configuración. LOGINFAILS

Este comando le permite limitar el número de entradas fallidas consecutivas de un usuario que se conecte. El formato del comando es loginfails

n

donde n es el número de entradas fallidas que quiera tolerar. Por ejemplo, si quiere que el sistema corte automáticamente la conexión de alguien que falla en introducir su contraseña después de tres veces, debería usar loginfails

PRIVATE

3

A veces encontrará necesario compartir archivos con otros a los que no quiera darles una cuenta en el sistema, pero al mismo tiempo no quiere situar el archivo en un directorio de acceso público. Mediante la configuración de un grupo público, pide a los clientes que usen los comandos SITE GROUP y SITE GPASS para incluirlos en los grupos privilegiados que quieren contraseña. Para que el servidor FTP soporte esta capacidad, necesita configurar el flag privado, usando el comando private

switch

donde switch es ON u OFF. Debido a que se requieren contraseñas para estos grupos especiales, necesitará usar el archivo /etc/ftpgroups. El formato de un grupo de acceso en /etc/ftpgroups es nombre-grupo-acceso:contraseña-encritada:grupo-real

donde nombre-grupo-acceso es el nombre que usa el cliente para referenciar el grupo especial, contraseña-encriptada es la contraseña que necesitan los usuarios para proporcionar (con SITE GPASS) para acceder al grupo y grupo-real es el grupo actual referenciado en el archivo /etc/group. Para generar la entrada de la contraseña encriptada de este archivo, necesita usar la función

Página 40

crypt. Se puede acceder a él a través de este script de Perl: #!/usr/bin/perl print "Introduzca la contraseña a encriptar: "; chop ($password=<STDIN>); print "LA contraseña encriptada es: ", crypt ($password, $password);

Simplemente escriba este script y guárdelo como un archivo. Cambie los permisos para hacerlo ejecutable (por ejemplo, chmod 755 mi-script-perl) y ejecútelo. Escribiremos la contraseña que quiera introducir y mostraremos la cadena encriptada resultante. Control de mensajes Cuando un usuario entra en su sistema mediante FTP, encontrará útil presentar algún tipo de mensaje a estos usuarios entrantes. En otras situaciones, encontrará práctico presentar un mensaje especial si introducen un directorio particular o realiza una cierta opción. Esta sección estudia cómo usar los comandos en el archivo /etc/ftpaccess de wu-ftpd para hacerlo. BANNER

Este comando le permite presentar un mensaje a un usuario que se conecte al servicio FTP, pero que no ha entrado aún. El formato de este comando es banner

nombre-archivo

donde nombre-archivo es el nombre de un archivo (con el path completo) que quiera mostrar. El archivo debe estar en formato texto ASCII. Por ejemplo: banner

/home/ftp/welcome_to_my_ftp_site

Nota Los administradores que gestionan servidores FTP muy utilizados comentan que un buen mensaje es crucial en la limitación del número de usuarios. EMAIL

El comando email le permite especificar la dirección de correo electrónico del administrador del sitio. Los comandos como message (que se explica más tarde) usan la información también. El formato de este comando es Email

dirección

donde dirección es la dirección de correo del administrador del sistema. Debería considerar usar una dirección de correo genérica del tipo [email protected] y usarla en el archivo /etc/aliases para expandir ese alias a todos los administradores reales. Un ejemplo del comando email en acción es email

MESSAGE

[email protected]

El comando message es útil cuando necesite configurar mensajes especiales para clases de usuarios específicas o para usuarios que entran en un directorio específico. El formato de este comando es: message

archivo

cuando

clase...

donde archivo es el archivo que se mostrará al usuario, cuando es la condición que deba cumplirse para mostrarse el mensaje y clase (que es opcional) es la lista de clases sobre la que se aplicará. El parámetro cuando puede tomar una de estas dos formas, LOGIN o CWD=path, y esta

Página 41

característica es la que hace este comando diferente del comando banner. • Si es LOGIN, el mensaje se visualizará después de una entrada al sistema correcta. • Si es CWD=path, el mensaje se mostrará cuando un usuario vaya al directorio path. El archivo del mensaje es un archivo de texto ordinario con algunas palabras claves. Estas palabras claves son las siguientes: Opción %T %F %C %E %R %L %U %M %N

Descripción Hora local. Espacio libre de la partición en la que está situado el path. El directorio de trabajo actual. La dirección de correo electrónico especificado con el comando e-mail. Nombre de máquina cliente. Nombre de máquina servidor. Nombre de usuario proporcionado por la hora de entrada. Número máximo de usuarios permitidos en la clase login. Número de usuarios en la clase.

Un ejemplo del comando message en acción es Message

./.demasiados.usuarios

LOGIN

anonusers

donde .demasiados.usuarios es un archivo parecido a éste: Lo siento %R, pero se han alcanzado %N de los %M usuarios de %L. Estamos trabajando para conseguir un servidor más grande pero mientras tanto le pedimos paciencia. Por favor, pruebe más tarde. Su Administrador FTP, %E

Nota Los mensajes desencadenados por la entrada de usuarios anónimos deben ser relativos al directorio FTP anónimo. README

El comando readme permite que el servidor informe automáticamente a un usuario cuando se actualiza un archivo en particular. El comando toma la forma Readme

archivo

cuando

clase

donde archivo es el nombre de path completo del archivo que quiere que muestre el servidor FTP, cuando es cuándo quiere que se le diga al usuario (el formato de cuando igual al del comando message) y clase es la clase sobre la que se aplicará. Los parámetros cuando y clase son opcionales. Por ejemplo: readme

./README

CWD=/pub/patches

Nota Los mensajes desencadenados por la entrada de usuarios anónimos deben ser relativos al directorio FTP anónimo.

Página 42

LOG Puede usar wu-ftpd para configurar sobre qué información se va a realizar log. Esta información es una manera estupenda de conseguir una buena forma de exponer y organizar sus servicios. Esta sección explica los comandos usados en la personalización de las entradas del log. LOG COMMANDS

Si quiere hacer log de cada comando introducido por los usuarios conectados a su servicio FTP, querrá usar los comandos de log. Su uso es el siguiente: log

commands

lista-tipo

donde lista-tipo es una lista separada por comas del tipo de usuario sobre cuyos comandos quiere hacer log, como el descrito con el comando class. Los tipos de listas válidos son: anonymous, guest y real. Por ejemplo, si quiere realizar log sobre todos los

comandos escritos por usuarios anónimos, debería introducir log

LOG TRANSFERS

commands

anonyrnous

Si quiere hacer log sólo sobre los archivos transferidos entre usuarios y su servidor en lugar de sobre todos los comandos introducidos, debería usar este comando: log

transfer

lista-tipo

direcciones

donde lista-tipo es el tipo de usuario sobre cuyos comandos quiere hacer log como el descrito con el comando class (es decir, anonymous, guest y real) y direcciones es una lista separada por comas de la dirección (entrante ó saliente) de la transferencia sobre la que se desea hacer log (es decir, inbound y outbound). Por ejemplo, para hacer log de las conexiones entrantes y salientes de los usuarios guest, escriba log

transfer

guest

inbound,outbound

Otros comandos de servidor Por supuesto, siempre hay comandos que no caen en ninguna de las categorías. Consideramos los siguientes: ALIAS

Con frecuencia es conveniente crear atajos para los directorios de acceso más frecuente. Mediante el uso del comando alias, puede hacer esto. El formato del comando es: alias

nombre-alias

directorio

donde nombre-alias es el propio alias y directorio es el directorio completo sobre el que quiere crear un atajo. Por ejemplo, alias

redhat

/pub/linux/distributions/redhat

debería permitir que un usuario que introduzca el comando cd redhat y vaya directamente al directorio /pub/linux/distributions/redhat. CDPATH

Equivalente a la variable de entorno PATH, cdpath le permite establecer un path de directorios para los usuarios que se conecten a su servicio FTP. El formato del comando es: cdpath

directorio

Página 43

donde directorio es el nombre del directorio que quiera añadir al path. Por ejemplo, si usa cdpath cdpath

/pub/linux /pub/recipes

y un usuario introduce el comando cd microwave, wu-ftpd debería buscar en los directorios siguientes: • • • •

./microwave Alias llamados microwave /pub/linux/microwave /pub/recipes/microwave

Nota La diferencia clave entre alias y cdpath es que alias especifica un mapeado simple desde un nombre de directorio a otro. Por otra parte, cdpath especifica una lista de directorios que se deben comprobar cuando un usuario utiliza el comando cd. COMPRESS

El servidor wu-ftpd ofrece la posibilidad de realizar conversiones de archivos sin uso de archivos intermedios. Una conversión específica puede comprimir o descomprimir un archivo antes de enviarlo a un usuario. Esto es especialmente útil para los clientes que no tengan la misma utilidad de compresión que la suya o para clientes con enlaces lentos que quieran comprimir un archivo antes de enviarlo a la red. El formato del comando es compress

switch

clase

donde switch es ON u OFF y clase es real, guest o anonymous. Lo malo de usar esta característica es que también debe tener configurado el archivo /etc/ftpconversions. Lo estudiaremos más tarde en este mismo capítulo. TAR

Como el comando compress, el comando tar permite a los clientes unir o desunir un archivo antes de bajárselo. El formato del comando es: tar

switch

clase

donde switch es ON u OFF y clase es real, guest o anonymous.

Nota Éste es un mecanismo estupendo para usuarios que se bajan subdirectorios de forma recursiva. Permisos La configuración de los permisos de archivos en un servidor FTP es muy importante. Necesita asegurarse de configurar los permisos correctos de los archivos para no compartir lo que no deba ser compartido y no alterar los archivos que no deban ser modificados. Los comandos que se analizan en esta sección le ayudan a mantener la integridad del sistema. CHMOD

Este comando le permite decidir si quiere dar a los usuarios el derecho a cambiar permisos de los archivos de sus sitios. (Deben ser propietarios de un archivo para ser capaces de cambiar sus permisos.) El formato del comando es chmod

switch

clase

Página 44

donde switch es ON u OFF y clase es real, guest o anonymous. En general, querrá dar este tipo de permiso únicamente a usuarios reales. Por ejemplo: chmod

DELETE

ON

real

El comando delete le dice al servidor si los usuarios tienen el derecho a eliminar archivos de su propiedad en el servidor FTP. El formato del comando es delete

switch

clase

donde switch es ON u OFF y clase es real, guest o anonymous. Por ejemplo: delete

OVERWRITE

ON

real

Este comando le permite decidir si los usuarios tienen el derecho a sobrescribir archivos existentes con sus bajadas. El formato del comando es: overwrite

switch

clase

donde switch es ON U OFF y clase es real, guest o anonymous. Por ejemplo: overwrite ON real

RENAME

El comando rename le permite decidir si quiere que los usuarios sean capaces de renombrar archivos de su propiedad en el servidor FTP. El formato del comando es: rename

switch

clase

donde switch es ON u OFF y clase es real, guest o anonymous. Por ejemplo: rename

UMASK

ON

real

El comando umask le permite decidir si quiere que los usuarios de su servidor FTP sean capaz de cambiar su máscara por defecto. La máscara de un usuario de termina qué permisos por defecto van a tener todos los archivos que crea. El umask está en octal y representa la inversa de lo que deberían ser sus permisos. Por ejemplo, una máscara 077 significa que cualquier archivo creado se podrá leer, escribir y ejecutar por su propietario, pero por nadie más. El formato del comando es umask switch clase

donde switch es ON u OFF y clase es real, guest o anonymous. Por ejemplo: umask ON real

PASSWD-CHECK

Los sitios proporcionan acceso anónimo a las peticiones de usuarios que introducen su dirección de correo como contraseña; wu-ftpd le permite decidir lo estricto que quiera ser para forzar la comprobación de contraseña si se ejecuta como un sitio anónimo. El formato del comando es passwd-check

strictness

enforcement :

donde strictness es none, trivial o rfc822 y enforcement es warn o enforce. Si strictness es none, el usuario sólo tiene que introducir algo en el campo contraseña y

Página 45

se le aceptará por wu-ftpd. Trivial sólo requiere que la dirección de correo tenga un símbolo @ en él. La especificación de rfc822 requiere que la dirección de correo sea completamente compatible con el Message Heder Standard (Estándar de cabecera de mensaje). Por ejemplo, [email protected] es una dirección de correo compatible con rfc822. Enforcement viene en dos formas: warn, lo cual significa que wu-ftpd avisará al usuario de que su contraseña no es compatible y después le deja acceso libre, y enforce, donde wuftpd no le permlte al usuario acceder hasta que proporcione una dirección válida. Observe que esto sólo afecta a los accesos anónimos. PATH-FILTER

El comando path-filter le permite aplicar un filtro a los nombres de archivos usados por los usuarios para descargar al servidor. El formato del comando es: path-filter

lista-tipo

mensaje

expres-reg-perm

expres-reg-deneg

donde lista-tipo es la lista de usuarios separada por comas a los que afecta este comando. Los tipos de usuarios aceptados son anonymous, guest y real. Mensaje es el archivo que se muestra al usuario si su nombre de archivo no pasa el filtro. Expres-reg-perm es la expresión regular que debe cumplir el nombre de archivo si el usuario lo quiere descargar. Expres-reg-deneg es la expresión regular que no debe cumplir el nombre de archivo si el usuario lo quiere descargar. Por ejemplo, la línea path-filter

anonyrnous

/home/ftp/.badfilename

UL*

gif$

nos dice que los usuarios anónimos deben empezar los nombres de sus archivos a descargar con las letras «UL» y no terminarlos con «gif». Si el nombre del archivo no cumple este criterio se enviará al usuario el contenido de /home/ftp/.badfile-name. UPLOAD

Puede usar el comando upload, junto con path-filter, para controlar los archivos situados en su servidor. El comando upload especifica los pennisos que tiene el cliente para colocar archivos en ciertos directorios, así como los permisos de los archivos que se pueden modificar. El formato del comando es upload

directorio

dir-glob

switch

propietario

grupo

perms mkdir

donde directorio es el directorio que se ve afectado por este comando, dir-glob es la expresión regular usada para determinar si un subdirectorio bajo directorio es un sitio válido para hacer una descarga y switch es YES o NO, estableciendo si la descarga puede realizarse en directorio. Los parámetros propietario, grupo y perms se establecen aquí (el propietario y grupo del archivo y sus permisos). Por último, puede especificar la operación mkdir como DIRS o NODIRS, determinando si el cliente puede crear subdirectorios bajo el directorio especificado. Por ejemplo: upload

/home/ftp

/incoming

yes

ftp

ftp

0400

nodirs

Nota El comando upload afecta sólo al directorio elegido, no a los subdirectorios que están por debajo de él. Esto previene que los usuarios remotos puedan crear directorios en su servidor y esconder archivos en él. El archivo log Como estudiamos antes, el archivo de log es importante en las operaciones del día a día. Con él, puede realizar un análisis de su sitio FTP y determinar cosas como los archivos más accedidos y los patrones de uso del sitio en general.

Página 46

La posición por defecto del archivo de log por defecto es /var/log/xferelog. Cada línea del log consta de una entrada, como la mostrada en la Tabla 13.1. Cabecera de entrada de Log Current-time

Descripción La fecha en que ocurrió la entrada. El formato de la línea es: DDD MMM dd hh:mm:ss AAAA

donde DDD es el día de la semana, MMM es el mes, dd es el día del mes, hh:mm:ss es la hora en horas, minutos y segundos y AAAA es el año. Tranfer-time El número de segundos que llevó realizar esta transferencia en particular. Remote-host El nombre de máquina del cliente. File-size Tamaño del archivo transferido. File-name Nombre del archivo transferido. Tranfer-type a para ASCII y b para binario. Special-action-flag Una lista de acciones realizadas por el servidor sobre el archivo: C significa que el archivo fue comprimido, U significa que fue descomprimido, T que se realizó un tar sobre él - (un guión) que no se realizó ninguna acción sobre él. Direction La dirección de la transferencia, donde o significa output (salida) e i significa input (entrada). Access-mode El tipo de usuario que realizó la transacción: a para anónimo g para invitado r para real. Username El nombre de usuario local si User-type es real. Service-name El nombre desde donde se invocó al servidor FTP. Authentication-method El tipo de autenticación hecho por el servidor sobre el usuario. 0 significa sin autenticación, 1 significa que el usuario entró con una combinación única de nombre de usuario y contraseña. Authentication-user-id Si el usuario entró con una combinación única de nombre de usuario y contraseña, se presenta el nombre de usuario aquí. Las transferencias anónimas se muestran como anonymous. Tabla 13.1. Entadas contenidas en cada línea de /var/log/xferlog Conversiones de archivo Algunas veces, los clientes no tienen las herramientas necesarias para hacer uso del archivo que se han bajado porque está comprimido o guardado en un formato que no puede leer (esto, particularmente cierto con los archivos .tar.gz hasta que WinZip empezó también a descomprimir estos archivos). Otras veces lo inverso también es cierto: el cliente es capaz de manejar los archivos comprimidos y podría preferir el archivo en un formato comprimido. Naturalmente, la compresión de archivos tiene muchos tipos de uso que puede configurar en el archivo /etc/ftpconversions. El formato del archivo es: strippre:strippost:addonpre:addonpost:external:type:options:desc

Los campos se muestran en la Tabla 13.2. Campo Strippre

Descripción El prefijo strip son los caracteres iniciales de un nombre de archivo que se eliminarán antes de transferir el archivo. Por ejemplo, si el prefijo strip vale «wedding» y el nombre de archivo completo es «wedding.ring», un usuario podría pedir simplemente un archivo «ring» y wu-ftpd sabría qué archivo

Página 47

conseguir así como qué clase de conversión debe realizar con él. " Strippost

El sufijo strip es igual al prefijo strip, excepto que funciona con la parte final del archivo. Por ejemplo, si el sufijo strip vale «.gz», y el nombre de archivo del servidor es «ring.gz», el servidor sabrá realizar la acción introducida en esta línea del archivo de configuración si el cliente le pide el archivo «ring».

Addonpost

El sufijo add-on es lo contrario de strippost. En lugar de eliminar el final de un archivo, lo añade. Esto se debería usar en el caso donde un archivo que, no se haya comprimido tenga .gz añadido como si lo estuviera y se envía al cliente.

Addonpre

El prefijo add-on es lo contrario a strippre. Permite añadir un prefijo al nombre del archivo antes de enviarlo a un cliente.

External

Esta entrada especifica qué programa (externo a wu-ftpd) se ejecuta cuando coincida un filtro. En el caso de las descargas, el archivo resultante de la conversión debería enviarse a la salida estándar de programas (stdout). Las descargas en el servidor se enviarán a la entrada estándar (stdin). Puede especificar el nombre de archivo que pidió el cliente en la línea de comandos mediante un comando externo mediante el uso de %s en lugar del propio nombre. El servidor buscará y reemplazará automáticamente cada ocurrencia de %s por el nombre del archivo del cliente.

Type

En el mundo de wu-ftpd, los archivos son de uno de estos tres tipos: regulares, ASCII o directorios (T_REG, T_ASCII y T_DIR, respectivamente). Este campo le permite especificar el tipo de archivo sobre el que wu-ftpd actuará si coincide el filtro del nombre de archivo. Puede especificar varias opciones separándolas con el símbolo pipe (|). Por ejemplo, T_REG|T_ASCII especifica que quiere que el filtro se aplique sobre cualquier tipo de archivo. Este campo decide si este filtro comprimirá, descomprimirá o realizará un tar sobre archivos. Cada opción se representa con O_COMPRESS, O_UNCOMPRESS y O_TAR, respectivamente. Puede hacer varias cosas sobre un archivo usando el símbolo pipe (|) entre los comandos. Por ejemplo, O_COMPRESS|O_TAR significa que el filtro comprimirá y hará un tar sobre la petición del cliente.

Options

Desc

Éste es un campo libre que le permite describir qué hace el filtro. Tabla 13.2. Campos del archivo /etc/ftpconversions

Una entrada ejemplo La siguiente es una entrada de ejemplo que comprime archivos bajo demanda usando gzip. Esto debería permitir a alguien que quiera conseguir el archivo orb_discography.tar, que el servidor lo comprima usando gzip antes de enviarlo. La configuración de la línea es la siguiente: :::.gz:/bin/gzip -9 -c %s:T_REG|T-ASCII:O_COMPRESS:GZIP

Los dos primeros parámetros (prefijo strip y sufijo strip) no son necesarios puesto que no tienen ningún valor. El tercer parámetro (prefijo addon) tampoco se aplica porque no tiene tampoco nada que añadir al comienzo del archivo. El cuarto parámetro, .gz (sufijo addon), especifica que el nombre del archivo debería tener añadido .gz después de ejecutar este filtro. El quinto parámetro (comando externo) especifica la invocación exacta del programa gzip a fin de realizar la compresión del archivo. Observe que usamos %s en lugar de un nombre de archivo. El sexto parámetro (tipo de archivo) le dice a wu-ftpd que puede realizar compresión sobre los archivos regulares y ASCII. El séptimo parámetro, O_COMPRESS (el campo opciones), le dice al servidor que la acción a realizar sobre el archivo es la compresión. Por último, el último campo es un recuerdo legible de que hace este filtro: ejecuta gzip. Aunque su apariencia intimida, no se preocupe! Es poco probable que necesite cambiar la configuración por defecto del archivo que viene con wu-fipd, puesto que cubre las conversiones más comunes.

Página 48

Configuración del acceso a la máquina El archivo /etc/ftphosts le permite explícitamente denegar o permitir usuarios basándose en su dirección IP original. Cada línea del archivo tiene la forma: allow nombre-usuario dirección

o deny nombre-usuario dirección

donde nombre-usuario es el nombre de usuario que utiliza cuando se conecta al servicio FTP y dirección es la dirección IP original. Puede añadir varias direcciones en la lista separadas por comas.

Configuraciones típicas Con todas las opciones disponibles, la configuración del servidor wu-ftpd puede amilanarle un poco, cuando no debería. Parecida a las configuraciones de DNS, las configuraciones más comunes son también muy fáciles de realizar. En esta sección recorreremos todas estas combinaciones para ayudarle a realizarlas. Acceso sólo anónimo Bajo el modelo UNIX, cada proceso debe tener un propietario. En el caso de un usuario FTP anónimo, este propietario debería tener unos derechos de acceso a archivos mínimos y únicamente ser capaz de ver los archivos del área FTP pública. Para llevar a cabo esto, necesita asegurarse de que está configurado el usuario «ftp» (esto se hace automáticamente en el Linux de Red Hat).

Configuración del usuario anónimo Truco Si usa el Linux de Red Hat, puede instalar el RPM anonftp-2.8-1.i386.rpm en lugar de recorrer todos los pasos que se explican en esta sección. Puede comprobar fácilmente si tiene un usuario anónimo examinando su archivo /etc/passwd. Si existe el usuario ftp, puede saltarse este paso. Si no lo tiene, querrá crear un nuevo usuario llamado ftp usando comandos parecidos a: # echo "/bin/ftponly" >>/etc/shells

y # useradd

-c "FTP User"

-d /home/ftp

-r

–s /bin/ftponly

ftp

El primer comando le dice al sistema que /bin/ftponly es una shell de usuario aceptable. Esto es necesario para que el comando useradd sea capaz de usarla, incluso si la shell no existe. La razón por la que querría configurar una shell que no existe, pero que esté presente en /etc/shells es que pueda entrar en el sistema mediante FTP, pero no mediante un telnet. El segundo comando crea una cuenta para el usuario ftp. Puede cambiar el directorio /home/ftp para colocarlo donde prefiera que ocurran los accesos FTP anónimos (una partición dedicada por si piensa hacer un gran sitio). También llama a la opción -r para que cree una cuenta del sistema, pues el directorio home no se crea automáticamente. Por motivos de estructuración, también debería crear un grupo ftp si no existe ya. Esto se hace con el comando: # groupadd

-r

ftp

El parámetro -r sirve para lo mismo que explicamos en el comando useradd. Con la cuenta creada, necesitará asegurarse de que está configurado el directorio home para el usuario ftp anónimo. Éste es el directorio que los usuarios verán cuando se conecten al servicio.

Página 49

Configuración del directorio FTP anónimo Truco Si usa el RPM anonftp-2.8-1.i386.rpm, puede saltarse estos pasos también, puesto que la estructura de directorios se configura por usted. El directorio FTP ánónimo debería tener los subdirectorios siguientes: pub bin etc lib

Los permisos de estos directorios deberían configurarse con los comandos siguientes: # # # # #

chown chown chmod chmod chmod

root.root bin etc lib root.ftp pub 111 bin etc 755 lib 2755 pub

Cuando el usuario ftp anónimo entra, el servidor realiza un chroot, una función de sistema que cambia la definición de cuál es el directorio raíz donde se localizan los archivos de FTP anónimos. En el caso en que los archivos FTP anónimos se localizan en /home/ftp, el comando chroot podría cambiar la definición del directorio raíz a /home/ftp, de forma que un cd / se referiría a /home/ftp. Esto hace que los usuarios anónimos no puedan ver otros archivos del sistema, especialmente los sensibles como /etc/passwd. El efecto de usar chroot es que los programas que se ejecutan deben estar disponibles en el nuevo directorio raíz, o no se podrán usar. Así, debe copiar los archivos que se muestran en la tabla siguiente en los directorios siguientes. (Nota: Asumimos que /home/ftp es el directorio donde se sitúan los archivos de ftp anónimos.) Archivo fuente /lib/ld-2.1.1.so /lib/libc-2.1.1.so /lib/libns1-2.1.1.so /lib/libnss_files- 2.1.1.so /usr/bin/compress /bin/cpio /bin/gzip /bin/ls /bin/sh /bin/tar

Destino /home/ftp/lib /home/ftp/lib /home/ftp/lib /home/ftp/lib /home/ftp/bin /home/ftp/bin /home/ftp/bin /home/ftp/bin /home/ftp/bin /home/ftp/bin

Permisos 755 755 755 755 111 111 111 111 111 111

Recuerde configurar correctamente los permisos de los archivos de arriba usando el comando chmod. También necesitará crear algunos enlaces simbólicos. Las series de comandos siguientes los crearan: # # # # # # #

cd ln ln ln ln cd ln

/home/ftp/lib -s ld-2.1.1.so ld-linux.so.2 -s libc-2.1.1.so libc.so.6 -s libnsl-2.1.1.so libnsl.so.1 -s libnss_files-2.1.1.so libnss_files.so.2 /home/ftp/bin -s gzip zcat

Y por último, necesitará configurar un archivo de grupo y de contraseña. El propósito de estos archivos no es de autenticación, sino de apariencia. Recuerde que el propietario de cada archivo se representa con un UID y que el archivo /etc/passwd da un mapeado de UID a nombres de usuarios. Lo mismo se aplica para grupos, GID y el archivo /etc/group. Así, necesitará crear el /home/ftp/etc/group con al menos lo siguiente: root: :0:

Página 50

ftp:*:XX:YY:::

donde XX es el GID del grupo ftp que estableció el comando groupadd en la sección anterior. El archivo /home/ftp/etc/passwd necesitará tener lo siguiente: root:*:0:0::: ftp:*:XX:YY:::

donde XX es el UID del usuario ftp creado por el comando useradd, e YY es el número de grupo del grupo ftp que estableció el comando groupadd.

Configuración de /etc/ftpaccess La clave de la configuración de un servidor FTP anónimo es el usuario ftp y los directorios apropiados. Una vez hecho esto, sólo necesita una configuración mínima del archivo /etc/ftpaccess. Un archivo ejemplo es: class class email loginfails limit readme readme message message compress tar chmbd delete overwrite rename log passwd-check

anonclass anonyrnous * nonanon real.guest * [email protected] 3 nonanon 0 Wk0000-2359 /home/ftp/.norealusers README* login README* cwd=* /welcome .msg login .message cwd=* yes anonclass yes anonclass no anonymous no anonymous no anonymous no anonymous transfers anonymous inbound,outbound rfc822 warn

Las líneas claves son las definiciones de clase donde separamos los usuarios no anónimos de los usuarios anónimos, y la línea limit, la cual limita los usuarios no anónimos a 0 para todos los días de la semana durante todo el día (los usuarios reales que traten de entrar son enviados al archivo /home/ftp/.norealusers). El resto del archivo es bastante genérico. Lo verá en muchas otras configuraciones diferentes.

Configuración del directorio /incoming Si necesita permitir que los usuarios anónimos depositen archivos en su sistema, necesitará configurar un directorio especial de entrada para ello. Los archivos situados allí se pueden recuperar sólo por el usuario root, no por ningún usuario anónimo. Esto es así para impedir a los individuos con intenciones deshonestas la entrada en el servidor FTP y aprovechar un sitio de acceso público para esconder pornografía, software pirateado o contenidos ilegales (como números de tarjetas de crédito robadas). Esto significa su supremacía sobre su labor como administrador de sistemas, pero un campo de protección es la única forma de asegurarse de que los archivos descargados en el servidor son aceptables para que otras personas se los bajen. Para crear este subdirectorio, vaya al directorio de FTP anónimo (por ejemplo, /home/ftp) y cree un subdirectorio llamado incoming así: # mkdir incoming

Entonces cambie los permisos para que sólo el usuario ftp pueda escribir allí, pero el usuario anónimo no pueda leer de él: # chmod 300 incoming # chown ftp.ftp incoming

y por último, añada las dos líneas siguientes a su archivo /etc/ftpaccess para controlar dónde descargan los archivos:

Página 51

upload upload

/home/ftp /home/ftp

* no /incoming

yes

ftp

ftp

0000

nodirs

El primer comando upload deniega la descarga sobre todos los directorios de su servidor FTP. El segundo comando abre explícitamente un directorio donde los usuarios anónimos pueden descargar archivos.

Usuarios sólo registrados y acceso mixto Es aceptable ejecutar un servidor que soporte acceso mixto, es decir, proporciona usuarios anónimos y usuarios de acceso regular a su servidor. Es también posible configurar un servidor con únicamente acceso para usuarios registrados. Acceso mixto Empezamos configurando el servidor como para un acceso sólo para anónimos. Una vez hecho, cambiamos el archivo /etc/ftpaccess para que refleje class email loginfails readme readme message message compress tar chmod delete overwrite renarne log passwd-check

all real,guest,anonymous * [email protected] 5 README* login README* cwd=* /welcome.msg login .message cwd=* yes all yes all no guest,anonymous no guest,anonymous no guest,anonymous no guest,anonymous transfers anonymous,real inbound,outbound rfc822 warn

Observe que esta configuración no proporciona acceso de descarga para los usuarios anónimos. Asumiendo que los directorios FTP anónimos están situados en /home/ftp necesitará añadir las líneas siguientes en el archivo /etc/ftpaccess: upload upload

/home/ftp /home/ftp

* no /incoming

yes

ftp

ftp

0000

nodirs

(Lea la sección de configuración de soporte de descarga en los servidores FTP anónimos para informarse de cómo configurar el directorio incoming.) Usuarios sólo registrados Hay dos mecanismos para denegar el acceso a los usuarios FTP anónimos. El primero es no tener el usuario ftp en el archivo /etc/passwd. Este método es muy simple y hace el trabajo. Sin embargo, si quiere dejar la configuración del FTP anónimo intacta, puede denegar el acceso FTP anónimo de la misma forma que deniega el acceso a los usuarios reales en un servidor FTP anónimo (usando el comando limit en el archivo /etc/ftpaccess). El archivo /etc/ftpaccess para este tipo de configuración debería ser: class class ernail loginfails limit readrne readrne message message compress tar

all real,guest * anon anonymous [email protected] 5 anon 0 Wk0000-2359 README* login README* cwd=* /welcome.msg login .message cwd=* yes all yes all

/home/ftp/

.noanonusers

Página 52

chmod delete overwrite renane log passwd-check

no guest no guest no guest no guest transfers real rfc822 warn

inbound,outbound

donde /home/fip/.noanonusers es el archivo de texto que se envía al cliente que trata de conectarse como anónimo para informarle de que no está permitido el acceso anónimo.

Configuración de un Servidor FTP Virtual Con wu-ftpd puede configurar varios servidores FTP sobre una sola máquina siempre que cada servidor tenga su propia dirección IP (ésta es una limitación de FTP, no de configurado un alias de IP y la tabla arp es conecta. Este recorrido rápido del proceso asume que tiene una tarjeta Ethemet y quiere añadir una dirección IP virtual: 1. Asegúrese de que las direcciones IP nuevas existen en la tabla de máquinas locales (/etc/hosts) así como en la tabla DNS. (En este ejemplo, llamaremos a la máquina earth.) 2. Ejecute el comando ifconfig para configurar el dispositivo eth0:0 con la dirección, máscara y broadcast apropiados. Por ejemplo, para configurar el dispositivo eth0:0 con la dirección 192.168.1.42, usaría: ifconfig eth0:0 192.168.1.42 netmask 255.255.255.0 broadcast 192.168.1.255

3.

Actualice la tabla arp. Necesitará la dirección hardware de su tarjeta Ethernet para esto. Ejecute el comando ifconfig -a para obtener esta información. Asumiendo que la dirección hardware de su tarjeta Ethemet es 00:10:4B:CB: 15:9F, escriba: arp -s earth OO:10:4B:CB:15:9F pub

Con su dirección IP virtual establecida, ahora necesitará crear una estructura de directorios similar a la de un sitio anónimo. Debería situarse en el directorio donde quiera hacer su sitio FTP virtual. Entonces añada el comando virtual al final de su archivo /etc/ftpaccess. El formato del comando es: Virtual

IP

tipo-fich

directorio

donde IP es la dirección IP de su servidor FTP virtual y tipo-fich es el tipo del archivo al que se refiere directorio. El valor de tipo-fich puede ser root, banner o logfile. Si tipo-fich es root, directorio debería ser el directorio donde se configuran los archivos de FTP anónimo para el sitio virtual. Si tipo-fich es banner o logfile, la entrada directorio será el archivo correspondiente. Por ejemplo, para configurar el servidor FTP virtual con la dirección IP 192.168.1.42, podría realizar mi configuración de este modo: virtual virtual virtual

192.168.1.42 192.168.1.42 192.168.1.42

root /home/earth banner /home/earth/.we1come.banner logfile /var/log/xferlog.earth

Nota Todos los archivos necesarios para el acceso FTP anónimo deben configurarse en el directorio raíz del servidor FTP virtual. En nuestro ejemplo, esto significa que los subdirectorios bin, etc, lib y pub están en el directorio /home/earth.

Conclusiones El demonio FTP de la Universidad de Washington (www.wu-ftpd.org) es un potente servidor de FTP que ofrece todas las características que debería necesitar para ejecutarse un servidor FTP comercial de un modo seguro. En este capítulo, analizamos el proceso de compilación, instalación y configuración de un servidor wu-ftpd. Específicamente, estudiamos:

Página 53

• • • • •

Todas las opciones de configuración de wu-ftpd. Establecimiento de servidores FTP virtuales. Configuración de servidores FTP anónimos. Configuración de servidores anónimos en conjunción con servidores FTP sólo para usuarios normales. Detalles acerca del protocolo FTP y sus efectos en los firewalls.

Esta información es suficiente para dejar a su servidor FTP humeando durante un buen rato. Naturalmente, como todo medio escrito sobre software, este texto tiene edad, y la información se volverá, de forma lenta pero segura, obsoleta. Asegúrese de visitar la página Web de wu-ftpd de vez en cuando para enterarse no sólo de los últimos desarrollos, sino también de la documentación más nueva.

Página 54

Capítulo 4 Introducción al Cliente FTP FTP (File Transfer Protocol) es un programa que se utiliza para transferir información, almacenada en ficheros, de una máquina remota a otra local, o viceversa. Para poder realizar esta operación es necesario conocer la dirección IP (o el "nombre") de la máquina a la que nos queremos conectar para realizar algún tipo de transferencia. Es fundamental distinguir entre máquina local y máquina remota: • Maquina Local: Es aquella desde donde nos conectamos para hacer la taransferencia, es decir, donde ejecutamos ftp. • Maquina Remota: Es aquella a la que nos conectamos para transferir información.

Ejecución del Cliente FTP Los pasos que hay que seguir para hacer FTP de una máquina (local) a otra (remota), son los siguientes: 1. Entrar en la máquina local (es decir, en la que vamos a trabajar físicamente) 2. Una vez dentro, nos conectaremos a la máquina remota, para lo cual haremos ftp, de una de las dos formas siguientes: $ ftp nombre o dirección IP de la máquina remota

o bién $ ftp FTP> open nombre o dirección IP de la máquina remota

Una vez hecho esto nos preguntará el nombre de usuario y la contraseña, es decir: Username nombre de usuario password palabra clave donde el nombre de usuario puede ser: 1. El username (login) de una cuenta en la máquina a la que voy a acceder; o bien 2. anonymous: para poder acceder al servidor de ficheros de la máquina remota. En este caso es aconsejable (y a veces obligatorio) introducir como palabra clave, la dirección de correo electrónico. Una vez hecho esto, ya se ha establecido comunicación con la máquina remota a través de FTP; por lo que el prompt del sistema desaparece y aparece el prompt del FTP, que es: FTP>

ó FTP-0>

A partir de este momento ya se pueden utilizar los comandos específicos del FTP.

Comandos del Cliente FTP Salir de una sesión de FTP Para salir de una sesión de FTP, se pueden utilizar los siguientes comandos: close quit bye

Termina la sesión de FTP, pero no sale del programa. Termina la sesión de FTP y sale del programa.

Obtener Ayuda FTP posee varios comandos para obtener ayuda de cómo utilizarlo: help ?

Dá una lista de los comandos del FTP de la máquina local

Página 55

help comando ? comando

Dá información sobre el comando especificado, correspondeinte a la máquina local

Manipulación de Archivos y Directorios A continuación se da una relación de comandos del FTP referentes al manejo de archivos y directorios. lcd directorio-local lcd unidad: cd directorio-remoto lls directorio-local dir directorio-remoto ls directorio-remoto ! comando delete fichero-remoto delete ficheros-remotos rmdir directorio-remoto mkdir directorio-remoto pwd

Para moverse de un directorio a otro en la máquina local Para cambiar de una unidad de disco a otra, en el caso particular de que la máquina local esa un PC Para moverse de un directorio a otro en la máquina remota Para listar el contenido de un directorio en la máquina local Para listar el contenido de un directorio en la máquina remota Para ejecutar un comando en la máquina local Para borrar un fichero en la máquina remota Para borrar varios ficheros en la máquina remota Para borrar un directorio en la máquina remota Para crear un directorio en la máquina remota Para saber el directorio en el que se está, en la máquina remota

Transferencia de Archivos Tipos de Transferencia Con FTP se puede realizar la transferencia de información en dos formatos diferentes: ascii y binario. Por defecto, la transferencia se hace en modo ascii. Para saber el tipo de formato que está activado para realizar las transferencias, se utiliza el comando: type

Para hacer la transferencia en formato ascii (lo hace por defecto), se utiliza el comando: ascii

ó type ascii

Para hacer la transferencia en formato binario, se utiliza el comando: binary

ó type binary

Transferencia Interactiva De acuerdo a como esté configurado, el cliente FTP, puede solicitar confirmación, o no, de cada archivo que va a transferir: esta configuración se llama Intercative Mode. • si está en Interactive mode on, va a pedir confirmación antes de transferir cada uno de los ficheros especificados. • si está en Interactive mode off, no va a pedir confirmación antes de transferir cada uno de los ficheros especificados. Para cambiar de mode on a off, o viceversa, se utiliza el comando prompt, cuya sintaxis, es simplemente:

Página 56

prompt

Transferencia de archivos desde la máquina Remota a la Local Para transferir un fichero de la máquina remota a la local, se utiliza el comando get o recv (ambos son equivalentes). La sintaxis es: get archivo-remoto

ó get (remote-file) archivo-remoto

Si se quiere cambiar el nombre del archivo que se va a transferir, se pondrá: get archivo-remoto archivo -local

Si se quieren transferir varios archivos de la máquina remota a la local, se utiliza el comando mget. La sintaxis es: mget lista de nombres de archivos-remotos

ó mget (remote-files) lista de nombres de archivos-remotos

Nota Los nombres de los ficheros van separados por blancos y pueden incluir los metacaracteres “*” y “?”.

Transferencia de archivos desde la máquina Local a la Remota Para transferir un fichero de la máquina local a la remota, se utiliza el comando put o send (ambos son equivalentes). La sintaxis es: put archivo-local

ó put (File) archivo-local

Si se quiere cambiar el nombre del archivo que se va a transferir, se pondrá: put archivo-local archivo-remoto

ó send archivo-local archivo-remoto

Si se quieren transferir varios archivos de la máquina local a la remota, se utiliza el comando mput. La sintaxis es: mput lista de nombres de archivos-locales

ó mput (remote-files) lista de nombres de archivos-locales

Nota Los nombres de los ficheros van separados por blancos y pueden incluir los metacaracteres “*” y “?”.

Página 57

Capítulo 5 Introducción a Servidores de Correo Elecrónico (e-mail) El e-mail (correo electrónico) se ha transformado en una herramienta casi indispensable debido en gran parte a su velocidad, es gratis y simple de usar. Hay 2 componentes que deben funcionar para ¨hacer e-mail¨. Por un lado el ¨cliente¨ (software que utilizan quienes envían y reciben correo). Ejemplos de ¨clientes¨: Outlook Express o Outlook de Microsoft y una variedad de clientes del mundo Open Source. Para Linux: Evolution, Pine (desarrollado por la Washington University) y Eudora son solo algunos ejemplos. Por el otro existe una infraestructura de servidores que realizan el envío, recepción y distribución. Ejemplo es Exchange 2000 de MS. Nuevamente el mundo Linux tiene varias alternativas. Algunas comerciales y otras Open Source y gratuitas. En la tabla 1 se puede ver una lista (en las diferentes columnas) de las mas reconocidas. Cada fila nos da su precio junto a las características mas importantes a tener en cuenta. La última fila nos da una clasificación de 1 a 10 (10 siendo considerado el mejor). Cuando se envía un e-mail este viaja entre 2 servidores de mail (mail servers). Se utiliza un protocolo conocido como SMTP (Simple Mail Transfer Protocol) que como lo indica su nombre realiza la transferencia entre los servidores. Como se distribuye el mail una vez que llegó a destino dependerá de cómo fue configurado.

Funciones de los mail servers Los servidores de correo realizan dos funciones diferentes 1. 2.

Relay (de posta) Recolección (Collection Server)

Lo normal es que un servidor cumpla ambos roles (de ¨relay¨ y ¨collection¨). Uno puede ¨levantar¨ un servidor SMTP propio para enviar y recibir correo pero se debe poner extremo cuidado en su configuración si no se quiere perder mails o enviar mails incorrectamente. Es muy importante al configurar el ¨relay¨ de no permitir que cualquiera (everybody) pueda acceder a el y usarlo como relay. Los que realizan Spam muy probablemente lo usaran y será ¨ese¨ server el culpable de la acción.

Relay Un ¨Relay Mail Server¨ hará un ¨forward¨ de un e-mail a otro servidor SMTP. Esto Sucede cuando los clientes se conectan a un SMTP server para enviar correo. La mayoría de los ISPS (Internet Service Providers, Proveedores de Internet) tienen un SMTP ¨Relay¨ server. Podría ser que un usuario tuviese su propio SMTP server y NO necesitase usar un ¨Relay¨.

Recolección Cuando llega un e-mail (por ejemplo a [email protected]) a un collection-server que regentea un dado dominio (cortech.com.ar), este lo distribuye al mailbox (buzón) correspondiente, esperando que el usuario José lo recoja usando el protocolo POP3 (Post Office Protocol3), IMAP4 (Internet Message Ardes Protocol), o un cliente de mail basado en comandos de shell como Mutt.

Spam y Virus Un mail server debe poder ayudar a combatir: 1. Spam 2. Virus Spam son e-mails que le llegan al usuario y que él no ha solicitado. Spam es un término muy usado para el llamado email no solicitado (Unsolicited Bulk o Comercial): UBE y UCE. Es casi imposible que el servidor de correo filtre 100% el Spam pero deberá sí limitarlo lo máximo posible. Un modo de evitar Spam es usar listas llamadas Realtime Blackhole List (RBL). Un ejemplo es MAPS que le permite al servidor de mails hacer DNS lookups de IPS y ver si están en las listas o no. Este es un servicio pago aunque existen alternativas gratis como DNSRBL.

Página 58

Los virus son una amenaza que llega junto a nuestros e-mails. Una vez que entran a nuestro sistema pueden atacarlo y/o usarlo como base para atacar otros sistemas. El mail server puede ayudar intentando verificar si un virus viene en el mail. Existen muchos programas comerciales que permiten chequear por virus los e-mails que le llegan. A continuación analizaremos los servidores de correo más populares. Algunos son Open Source y otros comerciales. Haremos una breve descripción y analizaremos sus características referidas a: seguridad y capacidad de filtrado (Spam y virus)

Servidores de e-mail conocidos QMail Un servidor de correo que fue diseñado bajo las normas impuestas en los RFC de la IETF. URL: www.qmail.org Costo: $0,QMail fue diseñado respondiendo en un 100% a los RFC (Request For Comments) de la IETF. Se destaca sus características de seguridad al punto que existe una recompensa de U$10,000 para cualquiera que pueda realizar un exploit de qmail. Aun esa recompensa permanece sin haber sido reclamada. Instalar qmail es simple aunque no es el estándar “./configure && make”. Configurarlo resulta aún más fácil. Tiene una opción en el make de modo de poder colocar algunas entradas de configuración. Con esto es suficiente para arrancarlo funcionando en una configuración básica. QMail tiene archivos de configuración, mayormente de una línea en /var/qmail/control. Allí entramos dominios y hostnames para envío y recepción. Cada archivo tiene un nombre simple, por eso es fácil adivinar cuál se necesita editar para un propósito específico. QMail puede manejar reparto por mbox o Maildir. Puede además canalizar su mail a través de cualquier aplicación que usted quiera, como por ejemplo SpamAssassin. Aunque no tiene ningún soporte para DNSRBL o para chequear los virus, es fácil configurar qmail para que mande todos los mails vía un chequeador de virus o un filtro de correo electrónico “basura” (spam filter). Uno de los mayores problemas con qmail es que levanta (forks) un proceso para cada mail individual que trate de enviar. Ya sean sea locales o remotos. Por defecto, simultáneamente, qmail enviará 20 mensajes remotos y 10 mensajes locales, lo cual debería ser más que suficiente para la mayoría de los sistemas. qmail hace básicamente reparto de mails pero existen más que suficientes parches disponibles ofreciendo encriptación TLS, configuración MySQL y conectividad IPv6 como también mejoras en el rendimiento y almacenamiento de colas para sistemas con grandes cantidades de mail. Si utiliza los parches de http://kldp.org/-enunjea/qmail_cocktail.php, qmail es un servidor de mail capaz de poder manejar grandes volúmenes de trafico. Muchas grandes organizaciones usan qmail.

SendMail Es el servidor de mail más popular de todo el mundo UNIX. URL: www.sendmail.org Costo: $0 Sendmail es el nombre de servidor de correo mas popular del mundo Linux (Unix en general). Y, se instala por defecto en casi “todas” las distribuciones. Es conveniente saber manejar sendmail y quizas luego usar otro. Escalea muy bien y tiene un sinnumero de características, incluyendo el soporte DNSRBL. El mayor problema con sendmail es que su sistema de configuración está basado en ´m4’. Este es un leguaje macro no difícil de dominar. Pero si implica que usted debe dedicarle una significativa cantidad de tiempo para descifrar cómo configurar sendmail de una forma segura y que haga lo que usted desee. A menos que uno desee tener un sendmail muy a medida tener que programar en m4 no es una buena opción. Por suerte la configuración por defecto es suficientemente buena para tener un servidor de correo básico.

Página 59

Si se puede dominar m4 (a través de la documentación sendmail o uno de los numerosos libros que existen) sendmail es un servidor muy poderoso y capaz. Como es tan popular existe una comunidad de usuarios de sendmail en internet muy grande y conocedora capaz de ayudarnos. Muchas distribuciones se están alejando de sendmail por sistemas más simples como Postfix y Exim. Si usted elige sendmail, asegúrese de estar al tanto con lo último en seguridad, ya que sendmail no tiene gran fama con los exploits. De todos modos si uno actualiza constantemente los sucesivos parches nos cubren.

Postfix Es muy fácil de configurar y esta resultando un reemplazo para sendmail. URL: www.postfix.org Costo: $0 Postfix comenzó originalmente como una alternativa (de más simple configuración) a sendmail. Desde su concepción como VMailer se ha desarrollado en un servidor de mail muy bueno y de sencilla puesta en marcha. Cambiar a Postix si esta sendmail funcionando es relativamente directo aunque deberemos reconfigurar bastante. Postfix puede ser usado para un amplio rango de aplicaciones, desde un simple servicio de mail, hasta un servidor de mail en gran escala. Lo mas comun es verlo como un simple re-enviador en workstations. Postfix puede fácilmente estar configurado para que lea opciones específicas de configuración, incluyendo dominios virtuales y aliases desde un archivo externo a la configuración principal. De esta forma es fácil agregar más dominios. Desafortunadamente, más allá de dbm, Postfix no soporta el uso de bases de datos como MySQL o PostgreSQL, para almacenar detalles de configuración Por esto no es ideal si se desea realizar una reconfiguración real-time. Mandrake Linux ha usado Postfix durante bastante tiempo como servidor SMTP por defecto. Esta facilidad en la configuración ha hecho maravillas en su uso, y por esto, la mayoría de las personas ya no lo abandonarán. Para configuración simple de mail servers Postfix es una opcion excelente. Si lo que uno está manejando es un gran número de dominios y quiere configuraciones complejas de dominios virtuales otros servidores pueden ser más apropiados.

Exim Es muy poderoso, escalable y bien documentado. URL: www.exim.org Costo: $0 Fue desarrollado en la Universidad de Cambridge, UK. Exim es un servidor de mail muy poderoso que ha sido diseñado para manejar grandes cantidades de mail y para limitar a UCE/UBE (spam) en la red. Muchas empresas que tienen gran cantidad de tráfico, incluyendo Sourceforge, usan Exim. Esto se debe básicamente por como escalea y ya que puede ser ajustado específicamente para las necesidades de los usuarios. Aunque usted tenga cinco usuarios detrás de su firewall o diez de mil cuentas, Exim puede manejar un gran rango de aplicaciones y ciertamente puede lidiar con casi todo lo que le den. Exim tiene una estructura de configuración muy completa, ofreciendo de todo desde ACLs (Access Control Lists) a soporte de base de datos desde MySQL y PostgreSQL a Oracle y DB2 de IBM. Sin embargo, no hay necesidad de aprender todos los aspectos de configuración para tener a Exim funcionando, ya que hay gran cantidad de documentos disponibles en el sitio de Exim. Expandir las capacidades del servidor es realmente fácil y la flexible estructura de configuración da una enorme cantidad de opciones para cada segmento de la organización. Muchas distribuciones, incluyendo Debian ofrecen Exim y sus configuraciones por defecto son muy completas y seguras. Estas distribuciones ofrecen herramientas de configuración que simplifican enormemente el setup. Como con la mayoría de las cosas del mundo Linux, O´Reilly ha producido un libro dedicado a Exim. Si Ud instala exim es un “must”. Aunque, la documentación propia del sitio de Exim es para recomendar. Exim es uno de los más poderosos sistemas de mail Open Source disponibles. Si lo comparo con sendmail debemos destacar la sencillez de su configuración. Y, no hay ninguna caracteristica esencial que no tenga. Esto lo diferencia de qmail ya que uno debe en este último depender de esfuerzo de terceros para tener ciertas caracteristicas especiales.

Página 60

SuSE Linux eMail Server 3.1 Toda su configuración puede hacer vía una interfase web. URL: www.suse.com Costo: U$S 999,SuSE siempre ha sido bien conocido por su muy popular distribución de Linux. Por esto no es sorprendente que ofrezcan un producto excelente para servidor de correo. Como muchos de sus otros productos, están apuntando con este servidor a compañías de tamaño medio que puedan mantener su propio sistema de email y pagar los fees correspondientes. El sistema ofrecido por SuSE está basado en un servidor SMTP e IMAP. Esto se complementa con una muy simple administración mediante un Web front-end. Todo lo que el administrador necesita hacer puede hacerse por medio de esta interfase. Por tanto no hay necesidad de configuración manual o investigaciones a fondo de las complejidades de SMTP. Por supuesto, entender es siempre requerido y, ciertamente uno no podría utilizarlo sin un poco de conocimiento sobre cómo funciona email. Pero no se requiere un nerd de redes o de Linux para hacer que funcione con éxito. Junto con los emails, la interfase maneja un calendario, la agenda de direcciones y una lista de tareas a realizar. A pesar de que cada una de estas son características son posible realizarlas por otros productos el hecho es que tenerlo disponible en un solo lugar, accesible a través de la red significa una ventaja para cualquiera que administre un servidor de mail. SuSE especifica que su sistema puede manejar alrededor de dos millones de usuarios, con entre cincuenta y doscientas personas accediendo al sistema simultáneamente montando un servidor de capacidad razonable. Esto es mas que suficiente en la mayoría de las situaciones. Este sistema está actualmente basado alrededor de Postfix utilizando un servidor LDAP para uso de la administración de usuarios. Por esto no es posible construir un sistema similar Open Source sin tener que gastar dinero en desarrollo. Como uno esperaría, es la facilidad de la configuración la que atrae a las personas a este sistema de SuSE. Aunque por su costo de U$S 999,- vale la pena ver las alternativas de Open Source.

GLMail Poderoso, fácil de usar y de instalar URL: www.ntmail.co.uk Costo: U$S 800,Gordano ha producido durante varios años un servidor de mail muy popular para Windows NT. Recientemente ha decidido migrarlo a Linux y otras plataformas Unix. La lista de características para GLMail son impresionantes junto a su facilidad de instalación y configuración. Es ideal para aquel que deasea un mail server en servicio, pero no desea perder el tiempo tratando de comprender qué está haciendo. La instalación es un proceso simple y GLMail no depende de ninguna distribución específica de Linux. Esto lo hace muy interesante para uno que está familiarizado con un estilo particular de Linux y no desea cambiar para solo instalar su servidor de mail. Todo es manejado a través de una interfase Web, permitiendo el control completo del servidor. Esto mantiene escondida del administrador los detalles de configuración. GLMail es particularmente popular por su capacidad de filtrado anti-virus y anti-spam. Es bueno bloqueando y tiene un bajo índice de falsos positivos lo que da confianza en el sistema. De este modo los usuarios no deben preocuparse que su servidor de mail devora sus mensajes importantes pensando que contienen algo desagradable o que son de una fuente spam. El soporte disponible para GLMail es ciertamente muy bueno y diferentes contratos pueden ser comprados dependiendo de las necesidades de nuestro propio negocio. Si usted está interesado en mirar a GLMail, puede bajarse un trial de 28 dias que está disponible en su web page. Con el filtrado de spam y el virus que tiene (lo cual generalmente no está disponible al mismo nivel con los productos de Open Source), GLMail está cerca de ser un “killer application”.

Página 61

Capítulo 6 Introducción a SendMail La mayoría de las distribuciones de GNU/Linux incluyen de manera predeterminada Sendmail, un poderoso servidor de correo electrónico ampliamente utilizado alrededor del mundo. Este requiere de una correcta configuración para su mejor aprovechamiento y poder disponer de un nivel de seguridad aceptable. Es muy común que los administradores inexpertos no se molesten siquiera en establecer un nivel de seguridad apropiado en sus redes locales, y mucho menos en el servidor de correo, el cual ven como un servicio más. Es un error común el configurar Sendmail para que permita enviar correo como sea a cualquier costo. Usualmente este costo significa convertirse en Open Relay, y por lo tanto en un paraíso para personas que se dedican al envío masivo de correo comercial (Spam).

Requisitos previos •

•

Usted tiene un dominio propio. o Que tiene un IP permanente o estática, y no una dinámica, y que se trata de un enlace dedicado, como E1, DSL, T1 o T3, etc. Es decir, usted NO se conecta a Internet por medio de un modem. Tiene perfectamente configurada su red local y parámetros de red del servidor. o Que usted utiliza Red Hat Linux 7.2, 7.3, 8.0 o 9 o al menos Sendmail-8.11.6 y xinetd-2.3.3.

Resultados a obtener • • •

Enviar y recibir correo electrónico. Establecer un buen nivel de seguridad. Filtrar el molesto Spam, o correo masivo no solicitado, que a muchos nos aqueja a diario, para toda su red local.

Requerimientos mínimos • • • •

Un servidor con al menos 32 MB RAM y alguna distribución de GNU/Linux® instalada. Deben de estar bien configurado los parámetros de red y un servidor de nombres -DNS-. Preferentemente, aunque no indispensable, deberá utilizar DOS tarjetas de red. Lo que si será obligatorio es disponer de al menos dos interfaces. Una para acceder a la red local y otra para acceder hacia Internet (una de estas puede ser virtual, o eth0:0, o bien una segunda interfaz real, o eth1). Tener instalados los paquetes sendmail, sendmail-cf, m4, make, xinet e imap que vienen incluidos en el CD de instalación o servidor FTP de actualizaciones para la versión de la distribución que usted utilice.

Tómese en consideración que, de ser posible, se debe utilizar la versión estable más reciente de todo el software que vaya a instalar al realizar los procedimientos descritos en este capítulo, a fin de contar con los parches de seguridad necesarios. Ninguna versión de sendmail anterior a la 8.11.6 se considera como apropiada debido a fallas de seguridad de gran importancia, y ningún administrador competente utilizaría una versión inferior a la 8.11.6. Por favor visite el sito Web de su distribución predilecta para estar al tanto de cualquier aviso de actualizaciones de seguridad. Ejemplo: para Red Hat Linux 7.2, 7.3, 8.0 y 9 hay paquetes de actualización en los siguientes enlaces: • ftp://updates.redhat.com/7.2/en/os/i386/, si su distribución es Red Hat™ Linux 7.2 • ftp://updates.redhat.com/7.3/en/os/i386/, si su distribución es Red Hat™ Linux 7.3 • ftp://updates.redhat.com/8.0/en/os/i386/, si su distribución es Red Hat™ Linux 8.0 • ftp://updates.redhat.com/9/en/os/i386/, si su distribución es Red Hat™ Linux 9

Página 62

Procedimientos Preparativos Lo primero será establecer que es lo que tenemos en la red local y que es lo que haremos con esto. Determine que máquinas de su red local, específicamente las direcciones IP, necesitan poder enviar y recibir correo electrónico y cuales NO deben hacerlo. Determine como desea recuperar los mensajes de correo electrónico que arriben al servidor. POP3 o IMAP. POP3 Es el protocolo de recuperación de correo electrónico más utilizado en la actualidad. Permite recuperar el correo pero este se almacenará localmente en el disco duro de las máquinas de los usuarios. IMAP Este protocolo almacena el correo electrónico, y permite la creación de carpetas de usuario, en el servidor. De modo tal, los usuarios pueden acceder desde cualquier parte del mundo a su buzón de correo y carpetas personales. IMAP también facilita la utilización de webmails (basado sobre Web). Determine el nombre de todos los posibles nombres o aliases que tenga su servidor. Ejemplo: mi-dominio.org, mail.midominio.org, servidor.mi-dominio.org, mi-red-local.org, mail.mi-red-local.org, etc. Configure sus dos tarjetas de red, una para la red local con la IP inválida y otra para la dirección IP real.

Verificando parámetros de red Debe de definirse el nombre de la máquina que funcionará como servidor de correo. Normalmente utilizaremos el esquema nombre_maquina.nombre_dominio. Un ejemplo del nombre de la máquina servidor sería linux.mi-dominio.org o servidor.mi-dominio.org. Así que asegúrese de que esto se encuentra perfectamente definido en /etc/sysconfig/network y /etc/hosts: Para /etc/sysconfig/network, es decir, el nombre que asignamos a la máquina, correspondería lo siguiente: NETWORKING=yes HOSTNAME=servidor.mi-dominio.org GATEWAY=148.243.59.254

Para /etc/hosts, es decir, la información de los hosts y las direcciones IP, correspondería lo siguiente: # Primero, verificamos que las direcciones IP del servidor estén asociadas # correctamente a un nombre largo y uno corto. 127.0.0.1 localhost.localdomain localhost 148.243.59.1 servidor.mi-dominio.org servidor 192.168.1.1 intranet.mi-red-local.org intranet # # Opcionalmente aquí puede agregar también los nombres # y direcciones IP de la máquinas de la red local. 192.168.1.2 maquina2.mi-red-local.org maquina2 192.168.1.3 maquina3.mi-red-local.org maquina3 192.168.1.4 maquina4.mi-red-local.org maquina4

Además de configurar correctamente un DNS que defina bien los DNS o servidores de nombres de dominios correspondientes. Esto debe hacerlo en el archivo /etc/resolv.conf, de un modo similar al siguiente: search mi-dominio.org # # El IP de la máquina que tiene el DNS de la red local. nameserver 192.168.1.1 # # Los DNS del proveedor de servicios. nameserver 200.33.213.66

Página 63

nameserver 200.33.209.66

Cuidado Se requiere un DNS perfectamente configurado para que este resuelva su nombre de dominio utilizado por el servidor de correo. Recuerde que el correo proveniente de otros equipos no llega solo al servidor ni tampoco por arte de magia.

Confirmando la instalación de Sendmail Es importante tener instalados los paquetes sendmail y sendmail-cf, ya que utilizaremos el servidor de correo Sendmail para el envío de nuestros mensajes y filtrado de correo masivo no solicitado -Spam-, y el paquete imap, mismo que nos permitirá utilizar el servicio de IMAP y POP3. Para asegurarse de esto, se puede utilizar la siguiente línea de comando: rpm -q sendmail sendmail-cf imap

Esto debe devolvernos las versiones de sendmail, sendmail-cf e imap que se tienen instaladas. Si no fuese así, debemos cambiar a root, si aún no lo hemos hecho, y proceder a instalar estos paquetes. Introduzca el CDROM de su distribución y siga el siguiente procedimiento: mount /mnt/cdrom cd /mnt/cdrom/RedHat/RPMS rpm -Uvh sendmail-* imap-* cd $home eject /mnt/cdrom

Debe instalar sendmail-cf o no le será posible compilar los archivos necesarios para configurar Sendmail. El paquete imap, el cual contiene el daemon para los protocolo POP3, es el que nos permitirá recuperar el correo desde el servidor en el resto de las máquinas que integren la red local con cualquier cliente de correo electrónico.

Configurando Sendmail Antes de continuar, debemos editar el fichero /etc/mail/local-host-names, en el cual deberemos de listar todos y cada uno de los aliases que tenga el servidor que estamos configurando, así como los posibles sub-dominios. Es decir, todos los dominios para los cuales estaremos recibiendo correo en un momento dado. # Incluya aquí todos los dominios para los que reciba correo. # mi-dominio.org servidor.mi-dominio.org mail.mi-dominio.org mi-red-local.org intranet.mi-red-local.org mail.mi-red-local.org

Procederemos entonces a modificar el archivo /etc/mail/sendmail.mc, con previo respaldo del original, a fin de preparar la configuración del servidor de correo. cp

/etc/mail/sendmail.mc

/etc/mail/etc/sendmail.mc.default

Por defecto Sendmail solo permitirá enviar correo solo desde la interfaz loopback (127.0.0.1), es decir, desde el mismo servidor. Si queremos poder enviar correo desde las máquinas de la red local comente la línea o bien, si tiene varias, añada las interfaces desde las cuales se quiere que escuche peticiones sendmail y omita las que no deben, como sería una red local secundaria con restricciones. dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

Página 64

Si queremos filtrar Spam de manera eficiente, la mejor manera de empezar a hacerlo es rechazando correo proveniente de dominios NO RESUELTOS, es decir dominios que no están registrados en un DNS y que por lo tanto SON inválidos. Para tal fin, a menos que se requiera lo contrario, es necesario mantener comentada la siguiente línea: dnl FEATURE(`accept_unresolvable_domains')dnl

Es necesario establecer que mi-dominio.org corresponderá a la máscara que utilizaremos para todo el correo que emitamos desde nuestro servidor. Debe, por tanto, añadirse una línea justo debajo de MAILER(procmail)dnl y que va del siguiente modo: MASQUERADE_AS(mi-dominio.org)dnl

Todo en conjunto, ya modificado, debería de quedar del siguiente modo (NO modificar el orden de las líneas): Configuración recomendada de sendmail.mc para Red Hat Linux 7.x. divert(-1) include(`/usr/share/sendmail-cf/m4/cf.m4') VERSIONID(`linux setup for Red Hat Linux')dnl OSTYPE(`linux') define(`confDEF_USER_ID',``8:12'')dnl undefine(`UUCP_RELAY')dnl undefine(`BITNET_RELAY')dnl define(`confAUTO_REBUILD')dnl define(`confTO_CONNECT', `1m')dnl define(`confTRY_NULL_MX_LIST',true)dnl define(`confDONT_PROBE_INTERFACES',true)dnl define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl define(`ALIAS_FILE', `/etc/aliases')dnl define(`STATUS_FILE', `/var/log/sendmail.st')dnl define(`UUCP_MAILER_MAX', `2000000')dnl define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl define(`confAUTH_OPTIONS', `A')dnl dnl TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl dnl define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl dnl define(`confTO_QUEUEWARN', `4h')dnl dnl define(`confTO_QUEUERETURN', `5d')dnl dnl define(`confQUEUE_LA', `12')dnl dnl define(`confREFUSE_LA', `18')dnl dnl FEATURE(delay_checks)dnl FEATURE(`no_default_msa',`dnl')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl FEATURE(`mailertable',`hash -o /etc/mail/mailertable')dnl FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')dnl FEATURE(redirect)dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(use_ct_file)dnl FEATURE(local_procmail)dnl FEATURE(`access_db')dnl FEATURE(`blacklist_recipients')dnl EXPOSED_USER(`root')dnl dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA') dnl FEATURE(`accept_unresolvable_domains')dnl dnl FEATURE(`relay_based_on_MX')dnl FEATURE(dnsbl, `blackholes.mail-abuse.org', `Rejected - see www.mail-abuse.org/rbl/')dnl FEATURE(dnsbl, `dialups.mail-abuse.org', `Rejected - see www.mail-abuse.org/dul/')dnl FEATURE(dnsbl, `relays.mail-abuse.org', `Rejected - see work-rss.mail-abuse.org/rss/')dnl FEATURE(`delay_checks')dnl MAILER(smtp)dnl MAILER(procmail)dnl MASQUERADE_AS(mi-dominio.org)dnl

Configuración recomendada de Sendmail.mc para Red Hat Linux 8.0 y 9 divert(-1)dnl

Página 65

dnl # dnl # This is the sendmail macro config file for m4. If you make changes to dnl # /etc/mail/sendmail.mc, you will need to regenerate the dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is dnl # installed and then performing a dnl # dnl # make -C /etc/mail dnl # include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`setup for Red Hat Linux')dnl OSTYPE(`linux')dnl dnl # dnl # Uncomment and edit the following line if your outgoing mail needs to dnl # be sent out through an external mail server: dnl # dnl define(`SMART_HOST',`smtp.your.provider') dnl # define(`confDEF_USER_ID',``8:12'')dnl define(`confTRUSTED_USER', `smmsp')dnl dnl define(`confAUTO_REBUILD')dnl define(`confTO_CONNECT', `1m')dnl define(`confTRY_NULL_MX_LIST',true)dnl define(`confDONT_PROBE_INTERFACES',true)dnl define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl define(`ALIAS_FILE', `/etc/aliases')dnl dnl define(`STATUS_FILE', `/etc/mail/statistics')dnl define(`UUCP_MAILER_MAX', `2000000')dnl define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl define(`confAUTH_OPTIONS', `A')dnl dnl # dnl # The following allows relaying if the user authenticates, and disallows dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links dnl # dnl define(`confAUTH_OPTIONS', `A p')dnl dnl # dnl # PLAIN is the preferred plaintext authentication method and used by dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do dnl # use LOGIN. Other mechanisms should be used if the connection is not dnl # guaranteed secure. dnl # dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl dnl # dnl # Rudimentary information on creating certificates for sendmail TLS: dnl # make -C /usr/share/ssl/certs usage dnl # dnl define(`confCACERT_PATH',`/usr/share/ssl/certs') dnl define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt') dnl define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem') dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem') dnl # dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's dnl # slapd, which requires the file to be readble by group ldap dnl # dnl define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl dnl # dnl define(`confTO_QUEUEWARN', `4h')dnl dnl define(`confTO_QUEUERETURN', `5d')dnl dnl define(`confQUEUE_LA', `12')dnl dnl define(`confREFUSE_LA', `18')dnl define(`confTO_IDENT', `0')dnl dnl FEATURE(delay_checks)dnl FEATURE(`no_default_msa',`dnl')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl FEATURE(redirect)dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl

Página 66

FEATURE(use_ct_file)dnl dnl # dnl # The -t option will retry delivery if e.g. the user runs over his quota. dnl # FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl FEATURE(`access_db',`hash -T -o /etc/mail/access.db')dnl FEATURE(`blacklist_recipients')dnl EXPOSED_USER(`root')dnl dnl # dnl # The following causes sendmail to only listen on the IPv4 loopback address dnl # 127.0.0.1 and not on any other network devices. Remove the loopback dnl # address restriction to accept email from the internet or intranet. dnl # dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl dnl # dnl # The following causes sendmail to additionally listen to port 587 for dnl # mail from MUAs that authenticate. Roaming users who can't reach their dnl # preferred sendmail daemon due to port 25 being blocked or redirected find dnl # this useful. dnl # dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl dnl # dnl # The following causes sendmail to additionally listen to port 465, but dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1. dnl # dnl # For this to work your OpenSSL certificates must be configured. dnl # dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl dnl # dnl # The following causes sendmail to additionally listen on the IPv6 loopback dnl # device. Remove the loopback address restriction listen to the network. dnl # dnl # NOTE: binding both IPv4 and IPv6 daemon to the same port requires dnl # a kernel patch dnl # dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl dnl # dnl # We strongly recommend not accepting unresolvable domains if you want to dnl # protect yourself from spam. However, the laptop and users on computers dnl # that do not have 24x7 DNS do need this. dnl # dnl FEATURE(`accept_unresolvable_domains')dnl dnl # dnl FEATURE(`relay_based_on_MX')dnl dnl # dnl # Also accept email sent to "localhost.localdomain" as local email. dnl # LOCAL_DOMAIN(`localhost.localdomain')dnl dnl # dnl # The following example makes mail from this host and any additional dnl # specified domains appear to be sent from mydomain.com dnl # MASQUERADE_AS('mi-dominio.org')dnl dnl # dnl # masquerade not just the headers, but the envelope as well dnl # FEATURE(masquerade_envelope)dnl dnl # dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well dnl # dnl FEATURE(masquerade_entire_domain)dnl dnl # dnl MASQUERADE_DOMAIN(localhost)dnl dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl dnl MASQUERADE_DOMAIN(mydomain.lan)dnl

Página 67

FEATURE(dnsbl, `blackholes.mail-abuse.org', `Rejected - see www.mail-abuse.org/rbl/')dnl FEATURE(dnsbl, `dialups.mail-abuse.org', `Rejected - see www.mail-abuse.org/dul/')dnl FEATURE(dnsbl, `relays.mail-abuse.org', `Rejected - see work-rss.mail-abuse.org/rss/')dnl FEATURE(`delay_checks')dnl MAILER(smtp)dnl MAILER(procmail)dnl

Luego

se

procesa

con

el

siguiente

comando

para

generar

/etc/sendmail.cf

(Red

Hat

Linux

7.x)

o

/etc/mail/sendmail.cf (Red Hat Linux 8.0 y 9):

Procedimiento en Red Hat Linux 7.x m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

Procedimiento en Red Hat Linux 8.0 y 9 m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Deben definirse los dominios para los cuales se estará permitiendo enviar correo electrónico. Esto se hace generando el archivo /etc/mail/relay-domains: mi-dominio.org.mx servidor.mi-dominio.org.mx mi-red-local.org.mx intranet.mi-red-local.org.mx

Abrimos ahora el archivo /etc/mail/access y agregamos algunas líneas para definir quienes podrán hacer uso de nuestro servidor de correo para poder enviar mensajes: # Por defecto, solo se permite enviar correo desde localhost...

localhost.localdomain localhost 127.0.0.1

RELAY RELAY RELAY

# Debemos añadir solo las direcciones IP que ahora tenga el servidor #

192.168.1.1 148.243.59.1 # # # # # # #

RELAY RELAY

Agregue también las direcciones IP que integran su red local. Solo especifique aquellas máquinas que tendrán permitido enviar y recibir correo. No es buena idea especificar redes completas. Especifique máquinas individuales, aunque signifique ingresar manualmente un centenar de entradas. Es más seguro de este modo.

192.168.1.2 192.168.1.3 192.168.1.4 # etc.

RELAY RELAY RELAY

# # Y también podemos agregar las direcciones de correo electrónico # de aquellos a quienes consideremos"indeseables", o que queramos # bloquear.

Spam@algun_Spamer.com info@otro_Spammer.com

REJECT REJECT

servidor.indeseable.com part.com.mx newlad.com dmc.com.mx propnewidea.com lapromocion.com hosting.com.mx solopromos.com.mx

REJECT REJECT REJECT REJECT REJECT REJECT REJECT REJECT

Página 68

# etc.

En este archivo también puede agregar las direcciones de correo electrónico que desee bloquear, como son las de quienes envían correo masivo no solicitado -Spam-. Al concluir, debemos también compilar este archivo para generar otro en formato de base de datos a fin de ser utilizado por Sendmail: cd /etc/mail Make

O bien puede ejecutar lo siguiente: makemap hash /etc/mail/access.db < /etc/mail/access

Será de utilidad designar un alias a la cuenta de correo de root a fin de recibir los mensajes generados por el sistema en una cuenta común de usuario. Abra el archivo /etc/aliases, en donde al final encontrará las siguientes líneas: # Person who should get root's mail # root: jperez

Esto corresponde a la cuenta de correo local hacia donde se re-direcciona el correo de root. Des-comente la última línea y asigne el nombre de la cuenta de usuario que utiliza normalmente: # Person who should get root's mail root: jperez

A fin de que este nuevo alias surta efecto y pueda ser utilizado por Sendmail debe utilizar el comando newaliases: newaliases

Terminados los detalles de la configuración, reinicie sendmail del siguiente modo y tendrá listo un servidor de correo que podrá utilizar para enviar mensajes para toda su red local utilizando el servidor SMTP de su proveedor de servicios: service sendmail restart

Generalmente Sendmail está incluido entre los servicios que de forma predeterminada se inician con el sistema. Si por alguna razón Sendmail no estuviese habilitado, ejecute lo siguiente a fin de habilitar sendmail en los niveles de corrida 3, 4 y 5: chkconfig --level 345 sendmail on

Si está funcionando un firewall, recuerde que debe de estar abierto el puerto 25, de otro modo el correo saldría pero no entraría. Añada o verifique que esté presente una línea en el guión de firewall similar a la siguiente: # SMTP iptables -t filter -A INPUT -p tcp -s 0/0 -d 0/0 --dport 25 -j ACCEPT

Habilitando los servicios POP3 e IMAP Si usted utiliza Red Hat Linux 7.x o versiones posteriores o equivalentes, debe saber que inetd ha sido sustituido por xinetd, y utiliza métodos de configuración muy distintos. Puede habilitar los servicios ipop3 (POP3 tradicional, autenticación en texto plano), pop3s (POP3 seguro, autenticación con criptografía), imap (IMAP tradicional, autenticación en texto plano) e imaps (IMAP seguro, autenticación con criptografía). Utilice aquellos que considere como más apropiados para su red local de acuerdo a las capacidades de los clientes de correo electrónico utilizados. Tome en cuenta que la autenticación por medio de texto plano es definitivamente un método inseguro, y siempre serán mejor usar los servicios que permitan establecer conexiones seguras.

Página 69

Puede habilitar los servicios de manera automática e inmediata ejecutando los siguientes comandos (solo habilite aquellos que realmente necesite): chkconfig chkconfig chkconfig chkconfig

ipop3 on pop3s on imap on imaps on

También puede habilitarlos manualmente con un editor de texto, lo cual es sugerido a fin de habilitar opciones adicionales, como direcciones IP específicas a las cuales se les estaría permitido cierto servicio. Acceda a al directorio /etc/xinet.d/ y edite los archivos ipop3, pop3s, imap e imaps, según lo requiera. Estos requerirán edite una sola línea para habilitar el servicio: service pop3 { socket_type wait user server log_on_success log_on_failure disable only_from localhost }

= stream = no = root = /usr/sbin/ipop3d += USERID += USERID = no = 192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.4

Lo mismo aplica para el protocolo IMAP e IMAPS. Hecho lo anterior, es necesario reiniciar el daemon xinetd con la siguiente línea de comando: service xinet restart

¿Que hacer con el Spam? Sin duda alguna una de las cosas más molestas de Internet es el correo comercial no solicitado, comúnmente llamado Spam. Las empresas que incurren en esta forma de marketing no tienen el mínimo respeto por los demás, y saturan cientos de miles de buzones de correo a diario. Las empresas que incurren en este tipo de promoción deberían ser boicoteadas y los responsables de enviar el correo deberían ser apedreados públicamente. Veremos un método civilizado para combatirlos. No importa cuanto se queje uno, o cuantos mensajes con insultos y llamada telefónicas reclamo se hagan a las oficinas de las empresas que incurren en esta poco ética forma de promoción, estas gentes no les interesa la opinión de a quienes ellos perjudican haciendo malgastar el ancho de banda o bloqueando servidores de correo. Ellos compran y hacen uso sin autorización de discos con cientos de miles de direcciones correo electrónico con un solo objetivo: promocionar como sea productos y servicios, en su mayoría, inútiles. El combate al Spam requiere de al colaboración de los administradores de las redes, quienes deben atender y dar seguimiento a las quejas y tomar las acciones ejemplares pertinentes. Los usuarios deben participar reportando incidentes a los administradores de las redes involucradas. Empresas que, por alguna razón, y gracias a lagunas legales, recurren al envío de Spam, pueden ser bloqueadas por completo añadiendo una entrada que rechace correo generado por los servidores de empresas que incurran en Spam. Esto se hace editando /etc/mail/access y generando /etc/mail/access.db. Ejemplo: newlad.com propnewidea.com lapromocion.com hosting.com solopromos.com

REJECT REJECT REJECT REJECT REJECT

Página 70

Acto seguido se ejecuta el siguiente comando: makemap hash /etc/mail/access.db < /etc/mail/access

Y se reinicia Sendmail. En adelante todo correo enviado desde los dominios anteriormente mencionados, será rechazado por completo para toda nuestra red. Otra opción más del administrador es bloquear también el acceso a los dominios involucrados a través de IPChains o IPTables. Esto no impedirá que llegue correo, pero servirá para boicotear a las empresas que utilizan Spam para promocionarse, al no permitir el acceso a sus redes desde nuestras redes locales. Para determinar la dirección IP de un dominio en particular, solo baste ejecutar el comando host, el cual devolverá la dirección IP y quizá algo de información adicional, como si se trata del alias de otro dominio. # host solopromos.com solopromos.com. has address 200.57.146.18

Una vez determinadas las direcciones IP problemáticas, solo hay que añadir algunas líneas en el guión de Firewall que se este utilizando de modo tal que queden bloqueadas de manera permanente, por lo menos desde nuestra red local. Ejemplo: iptables -A INPUT -s 216.219.236.81 -d 0/0 -j DROP iptables -A INPUT -s 64.65.27.126 -d 0/0 -j DROP iptables -A INPUT -s 200.57.146.18 -d 0/0 -j DROP

Mientras más usuarios y administradores participen reportando y castigando el Spam, correspondientemente, esta molestia desaparecerá eventualmente, o al menos haremos saber a quienes se promocionan de este modo que NO NOS AGRADA lo que hacen.

El Servidor de Nombres (DNS) Si el servidor DNS se localiza en otro servidor y es administrado por otras personas, solo bastará con informar al administrador de dicho servidor de nombres la existencia del nuevo servidor de correo electrónico, a fin de que se de de alta la entrada correspondiente en el DNS y a su vez a fin de que el NIC lo tome en cuenta en el siguiente ciclo de refresco. Si desea configurar DNS propio, y dar éste de alta con el NIC, se necesitará tener instalados los siguientes paquetes: bind, bindutils y caching-nameserver. Todos, seguramente, vienen incluidos en alguno de los CD de instalación. Note por favor que no es conveniente utilizar versiones anteriores a bind-9.1.3, debido a serias fallas de seguridad. Consulte en el sitio Web de su distribución para verificar si hay paquetes de actualización disponibles. Nota Para información detallada de cómo instalar, configurar y mantener un servidor DNS, vea el LOC 1-2-3, Capítulo 13.

Página 71

Configuración de los clientes de correo Considerando que tiene bien configurada su red local y que ha seguido este capítulo al pie de la letra, sea la PC que sea en su red local, puede configurar mail.mi-red-local.org o mail.mi-dominio.org como servidor de correo saliente o SMTP y servidor de correo entrante, POP3 o IMAP, en el cliente de correo que utilice.

Figura 1 - Preferencias de Netscape para los servidores de correo

Página 72

Capítulo 7 Introducción a Horde (WebMail) ¿Qué es Horde? Horde es un programa (software) y un proyecto. El Proyecto Horde comprende un conjunto de aplicaciones basada en Web (Web based) de productividad, mensajería, y administración de proyectos. Detalle de estas están descritas más adelante. El Horde Framework es un código de base común a todas las aplicaciones Horde, incluyendo librerías y un ainterfase de usuario común a ellas. Horde y sus componentes están escritos en PHP. El proyecto Horde (www.horde.org) tiene una gran cantidad de componentes donde se destacan: IMP, Turba, Kronolith, Jonah, WHUPS, Chora y Gollem.

¿Qué es IMP? IMP es Internet Messaging Program (antiguamente era, entre otras cosas, IMAP webMail Program), un sistema webmail basado en PHP y componente del proyecto Horde. IMP es el más maduro de los componentes de Horde, y es el más ampliamente desarrollado (¡hasta ahora!). IMP, una vez instalado, accede al mail a través de IMAP, requiriendo poca a ninguna preparación especial en el servidor en el cual se almacena el correo. IMP ofrece muchas de las características que los usuarios esperan de sus programas de mails convencionales, incluyendo anexos, corrector ortográfico, múltiples carpetas, y soporte de múltiples lenguajes.

¿Qué es Turba? Turba es la libreta de direcciones y administrador de contactos de Horde. Reemplaza el simple administrador de contactos que fue parte de versiones anteriores de IMP.

¿Qué es Kronolith? Kronolith es un calendario y organizador diario (think Day-Timer) basado en la web.

¿Qué es Jonah? Jonah es un administrador de contenidos y presentaciones basado en PHP y diseñado para manejar un sitio tipo portal usando RDF, RSS y contenido de segundo plano XML. Sigue en la fase de desarrollo.

¿Qué es WHUPS? WHUPS es el Web-based Horde Unified Project System. Esta basado en PHP y es un sistema de administración de proyectos. WHUPS implementa un sistema muy flexible de rastreo de fuentes, y en el futuro estará integrado por Chora y otro desarrollados de Horde relacionados con desarrrollo y administración proyectos.

¿Qué es Chora? Chora es una aplicación para ver repositorios de código que son manejados usando el sistema de control de fuente (source code system) CVS. Provee una vista, basada en la web, de cualquier repositorio CVS. Ahora incluye de soporte anotaciones, Visual Branco Beijing y diffs legibles por humanos.

¿Qué es Gollem? Gollem es el administrador de archivos de Horde, y provee una interfase común para acceder a los sitios FTP, sistema de almacenamiento local de archivos, y un almacenamiento de sistema de archivo SQL virtual. Todavía en desarrollo están varios de sus componentes.

Solamente quiero WebMail. ¿Por qué necesito Horde? Si sólo necesita la funcionalidad de un solo componente, puede simplemente instalar ese componente; sin embargo, todos los componentes se basan en un código común en el mismo paquete Horde. Aunque instale un componente o todos los

Página 73

componentes, necesita instalar Horde. Entonces, si solo quiere ofrecer un email basado en Web (en gran medida, el uso más común de aplicaciones Horde hasta ahora) necesitará instalar Horde e IMP.

¿Cuánto cuesta Horde? Horde, y todos sus componentes, son gratis, siendo liberado bajo GNU Public License (Licencia Pública GNU).

¿En qué plataformas funciona Horde? Horde está desarrollado en Unix, con el servidor web Apache. Pero debería funcionar correctamente en cualquier UnixGNU/Linux en el que usted pueda instalar Apache y PHP.

¿Horde funciona en Windows 95 o en NT/2K/XP? Horde y todos los Componentes de Horde trabajan bajo Windows NT/2K/XP con Apache y PHP4 con un rendimiento aceptable. IMP y Turba, se supone trabajan también en Windows NT/2K con IIS y PHP4.

Página 74

Capítulo 8 Introducción a Administración Remota La administración remota siempre ha constituido un reto para los administradores de redes, para situaciones particulares dentro y fuera de la red física en la cual están conectados los servidores. Ya sea porque la distribución física de los servidores no permite que estén todos en un “centro de cómputos” ó porque desea administrar los servidores sin levantarse de su silla, también para el caso que necesite administrar servidores que se encuentran en distintas sucursales ó acceder a recursos de la empresa cuando esté de viaje o en su casa. El acceso remoto con propósitos de administración es la solución para estas situaciones.

Diferentes tipos de Administración Remota Desde un principio vamos a aclarar que existen distintas maneras de realizar el mismo propósito: Control Remoto, Sesión Remota y Acceso Remoto. Todas pueden utilizarse en cualquier topología de conexión: dentro de una LAN ó a lo largo de una conexión WAN ó simplemente por medio de Dial-Up (modem), aunque es necesario tener en cuenta las características de cada una antes de su implementación, para evaluar sus pros y sus contras respecto de cada tipo de conexión.

Control Remoto Las soluciones de control remoto, por definición, permiten tomar control de una PC (Workstation ó Server) extendiendo, a lo largo del medio físico que estemos utilizando, solamente las capacidades de los dispositivos de entrada-salida (mouse, teclado y display) de esa PC. El software que permite esto, típicamente consta de dos partes, una es la que se instala en la PC que será controlada (host) y la otra se instala en la PC que tomará el control (remote). El tráfico de datos, sobre el medio físico, entre el host y el remoto se reduce exclusivamente a órdenes de entrada-salida y display, todo el procesamiento y ejecución de aplicaciones se realiza en la PC que actúa de host. Al iniciar una conexión de control remoto sobre una PC, existe la opción de elegir qué grado de control tiene el remoto sobre los dispositivos de entrada-salida, puede ser mínima (solamente ver el display), compartida (ver el display; dominar teclado y mouse en forma conjunta con el host) o total (la PC host pierde el control sobre el teclado, mouse y display). Cabe aclarar que este tipo de software muestra solamente lo que esta ocurriendo en la PC a la cual esta conectada, durante el período de control remoto; entendiendo con esto que si hay un usuario trabajando en esa PC, se podrá “ver” absolutamente todo lo que está haciendo. En caso de interrumpirse la conexión, la PC quedará en el estado en que se encontraba mientras se estaba tomando control de ella, con los riesgos que esto implica (archivos y aplicaciones abiertas, etc.). Software que permiten hacer control remoto: Symantec pcAnywhere, VNC, GoToMyPC, RAdmin, Carbon Copy.

Sesión Remota En todo lo que se refiera al medio físico sobre el cual se establece una sesión remota, y los datos que viajan por él, una sesión remota comparte las características con las de Control Remoto. La PC desde la cual iniciamos una sesión remota tendrá control de teclado, mouse y display. Al iniciar una Sesión Remota, lo que realmente estamos haciendo es iniciar una conexión a una PC (Server) que nos permite tener todo un entorno de trabajo (ya sea en modo texto o gráfico) dedicado a nuestra conexión. Si más de un usuario se conecta por medio de sesiones remotas a un servidor, cada uno de los usuarios tiene su propio entorno de trabajo, capacidades individuales de ejecución de programas, etc. Software que permite hacer sesión remota en modo texto (TelNet, SSH, etc.): Century TinyTERM, HummingBird Exceed, PuTTY. Software que permite hacer sesión remota en modo gráfico: VNC (con servidores Microsoft no es posible hacer multi-sesión grafica), Windows Terminal Services. Salvo Windows Terminal Services, los demás protocolos y productos son cross-platform (multiplataforma).

Acceso Remoto A diferencia de las metodologías de control remoto y sesión remota, la tecnología de acceso remoto, apunta a que el usuario se incorpore como un nodo más a la topología existente en una red. Al hacer esto, la PC (nodo) ve todo el tráfico, y participa activamente, de la red a la cual se está conectando. Todo el procesamiento y ejecución de aplicaciones se realiza en la PC Local

Página 75

y todo el tráfico de datos ó documentos que obtenga de las demás PCs de la red (Workstations o Servers) viajará hasta la PC Local. La principal restricción de esta metodología es que cuanto más lento sea el tipo de conexión, más lenta se volverá la respuesta desde la red a la que se ha conectado.

Direcciones Web relacionadas Carbon Copy Century TinyTERM GoToMyPC HummingBird Exceed PuTTY RAdmin Symantec pcAnywhere VNC Windows Terminal Services

www.codework.com www.censoft.com www.gotomypc.com www.hummingbird.com/products/ www.chiark.greenend.org.uk/~sgtatham/putty/ www.famatech.com www.symantec.com www.realvnc.com www.microsoft.com

Página 76

Capítulo 9 Introducción a TelNet El protocolo diseñado para proporcionar el servicio de conexión remota (remote login) recibe el nombre de TELNET, el cual forma parte del conjunto de protocolos TCP/IP y depende del protocolo TCP para el nivel de transporte. El protocolo TELNET es un emulador de terminal que permite acceder a los recursos y ejecutar los programas de un ordenador remoto en la red, de la misma forma que si se tratara de un terminal real directamente conectado al sistema remoto. Una vez establecida la conexión el usuario podrá iniciar la sesión con su clave de acceso. De la misma manera que ocurre con el protocolo FTP, existen servidores que permiten un acceso libre cuando se especifica "anonymous" como nombre de usuario. Es posible ejecutar una aplicación cliente TELNET desde cualquier sistema operativo, pero hay que tener en cuenta que los servidores suelen ser sistemas VMS o UNIX por lo que, a diferencia del protocolo FTP para transferencia de ficheros donde se utilizan ciertos comandos propios de esta aplicación, los comandos y sintaxis que se utilice en TELNET deben ser los del sistema operativo del servidor. El sistema local que utiliza el usuario se convierte en un terminal "no inteligente" donde todos los caracteres pulsados y las acciones que se realicen se envían al host remoto, el cual devuelve el resultado de su trabajo. Para facilitar un poco la tarea a los usuarios, en algunos casos se encuentran desarrollados menús con las distintas opciones que se ofrecen. Los programas clientes de TELNET deben ser capaces de emular los terminales en modo texto más utilizados para asegurarse la compatibilidad con otros sistemas, lo que incluye una emulación del teclado. El terminal más extendido es el VT100, el cual proporciona compatibilidad con la mayoría de los sistemas, aunque puede ser aconsejable que el programa cliente soporte emulación de otro tipo de terminales.

Telnet en Linux En la mayoría (por no decir todas) las distribuciones linux, el servicio telnet, depende del demonio telnetd, este demonio se “levanta” (inicia) bajo demanda. El demonio encargado de administrar el inicio y la parada del demonio telnetd, es el demonio xinetd ó inetd (dependiendo de la distribución de linux y del kernel que tenga dicha distribución). Nota Para información detallada de cómo instalar, configurar y mantener el demonio xinetd, vea el LOC 1-2-3, Capítulo 9.

Telnet en Windows 2000 El servidor (servicio) de Telnet que implementa Microsoft en Windows 2000 hace un intento de mejorar la seguridad al compararlo con Telnet UNIX-like: soporta autenticación NT LAN Manager (NTLM) que encripta los passwords. Uno puede forzar al daemon a aceptar solo passwords autenticados por NTLM y que rechaze otros. Pero, esto lo hace muy restrictivo. Windows 2000 levanta con este tipo de autenticación por defecto pero luego el administrador debera degradar esto si quiere conectarse a servidor NO Windows 2000. O sea solo nos ayuda cuando se conectan 2 Windows 2000. Independientemente de que tipo de autenticación se use el resto de lo que va y viene por la red desde una maquina a la otra va en texto plano (clear text). Es decir alguien que snifee la red podra ver nuestras acciones. La solucion a esto vino hace años del mundo Unix: Secure Shell SSH. Como dijimos telnet esta por default en W2K. Podemos comenzar el servicio haciendo: net start

tlntsvr

Si desea que el servicio comience automáticamente: 1. Boton derecho sobre “my computer” 2. Bajo “Computer Management” vera “services and Applications”. Abralo clickeando el signo +. 3. Alli vera “services”. Clickeelo y vera los servicios disponibles sobre el panel derecho. 4. Busquemos Telnet. Haga boton derecho y busque propiedades 5. Del drop-down elija automatic.

Página 77

Para telnetear un servidor hacemos telnet nombre_del_servidor

ó telnet direccion_IP

Podemos modificar el modo en que el cliente autentica. Por ejemplo que acepte nombre de usuario y password: 1. escriba en linea de comandos tlntadmn

2. 3. 4. 5. 6. 7. 8.

Elija 3 y haga enter. Esto permitira modificar el REGISTRY Elija 7 y enter . El default es 2. Significa NTLM como describimos ponga opcion 1 . Diga y … ponga 0 para modificar el REGISTRY S para stopear el servicio 4 para recomenzar 0 para salir del tlntadmn

Pruebe telnetear una máquina con UNIX.

Página 78

Capítulo 10 Introducción a SSH OpenSSH es una implementación libre del protocolo SSH (Secure Shell) que permite el acceso remoto hacia sistemas. Su principal ventaja radica en que se utiliza un túnel seguro para la transmisión de datos, algo de lo que carecen protocolos como FTP y Telnet, que son precisamente los protocolos a reemplazar.

Software requerido. • • •

openssh-3.5p1-6 openssh-clients-3.5p1-6 openssh-server-3.5p1-6

Antes de continuar verifique siempre la existencia posibles actualizaciones de seguridad. Para Red Hat Linux 8.0 y 9 hay paquetería de actualización en los siguientes enlaces: • ftp://updates.redhat.com/7.2/en/os/i386/, si su distribución es Red Hat™ Linux 7.2 • ftp://updates.redhat.com/7.3/en/os/i386/, si su distribución es Red Hat™ Linux 7.3 • ftp://updates.redhat.com/8.0/en/os/i386/, si su distribución es Red Hat™ Linux 8.0 • ftp://updates.redhat.com/9/en/os/i386/, si su distribución es Red Hat™ Linux 9

Archivos de configuración El archivo de configuración central del daemon sshd es /etc/ssh/sshd_config.

Procedimientos Tome el editor de texto de su preferencia y edite /etc/ssh/sshd_config. A continuación analizaremos los parámetros a modificar.

Parámetro ListenAddress Por defecto SSHD escuchará peticiones por todas las interfaces del sistema. En algunos casos es posible que no se desee esto y se prefiera limitar el acceso solo a través de una interfaz que solo se pueda acceder desde la red local. Para tal fin puede establecerse lo siguiente, considerando que el servidor a configurar posee la IP 192.168.1.254: ListenAddress 192.168.1.254

Parámetro PermitRootLogin Este parámetro sirve para establecer si se va a permitir el acceso directo del usuario root al servidor SSH. Si se va a permitir el acceso hacia el servidor desde redes públicas, resultará prudente utilizar este parámetro con el valor no. PermitRootLogin no

Parámetro X11Forwarding Este parámetro establece si se permite o no la ejecución remota de aplicaciones gráficas. Si se va a acceder hacia el servidor desde red local, este parámetro puede quedarse con el valor yes. Si se va a permitir el acceso hacia el servidor desde redes públicas, resultará prudente utilizar este parámetro con el valor no. X11Forwarding yes

Página 79

Aplicando los cambios. Sshd puede inicializarse, detenerse o reinicializarse a través de un guión similar a los del resto del sistema. De modo tal, podrá inicializarse, detenerse o reinicializarse a través del comando service y añadirse al arranque del sistema en un nivel o niveles de corrida en particular con el comando chkconfig. Para ejecutar por primera vez el servicio, ejecute: service sshd start

Para hacer que los cambios hechos a la configuración surtan efecto, ejecute: service sshd restart

Para detener el daemon, ejecute: service sshd stop

Por defecto sshd está incluido en todos los niveles de corrida con servicio de red. Para deshabilitar el servicio Sshd de los niveles de corrida 2, 3, 4 y 5, ejecute: chkconfig --level 2345 sshd off

Probando OpenSSH. Acceso por shell. Para acceder a través de shell hacia el servidor, basta con ejecutar desde el sistema cliente el comando ssh definiendo el usuario a utilizar y el servidor al cual conectar: ssh usuario@servidor

Acceso por SFTP OpenSSH incluye además un servidor de archivos en modo seguro que permite sustituir las transferencias a través de protocolo FTP, el cual envía todos los datos en texto simple. Para acceder a través de SFTP hacia el servidor, basta con ejecutar desde el sistema cliente el comando sftp definiendo el usuario a utilizar y el servidor al cual conectar: sftp usuario@servidor

El shell es casi idéntico al de FTP y tiene las mismas funcionalidades.

Página 80