Professional Documents
Culture Documents
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:
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 pseudo-
lenguaje) un conjunto de reglas de un firewall del primer gráfico:
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.
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.
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.
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para proteger la propia máquina
## FLUSH de reglas
iptables –F
iptables –X
iptables –Z
iptables -t nat –F
## Empezamos a filtrar
# El localhost se deja (por ejemplo conexiones locales a mysql)
/sbin/iptables -A INPUT -i lo -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
# Y el resto, lo cerramos
iptables -A INPUT -p tcp --dport 20:21 -j DROP
iptables -A INPUT -p tcp --dport 22 -j DROP
iptables -A INPUT -p tcp --dport 3306 -j DROP
iptables -A INPUT -p tcp --dport 10000 -j DROP
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:
# 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
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.
¿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
## FLUSH de reglas
iptables –F
iptables –X
iptables –Z
iptables -t nat –F
## 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
Página 11
echo 1 > /proc/sys/net/ipv4/ip_forward
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:
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.
Página 12
echo -n Aplicando Reglas de Firewall...
## FLUSH de reglas
iptables –F
iptables –X
iptables –Z
iptables -t nat –F
## 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
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
#!/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 de reglas
iptables –F
iptables –X
iptables –Z
iptables -t nat –F
## 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
# Abrimos el pop3
iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport 110 -j ACCEPT
Página 14
iptables -A INPUT -s 211.45.176.24 -p tcp --dport 1723 -j ACCEPT
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.
Página 15
Figura 7: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos.
¿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 de reglas
iptables –F
iptables –X
iptables –Z
iptables -t nat –F
## 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
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
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
#!/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 de reglas
iptables –F
iptables –X
iptables –Z
iptables -t nat –F
## 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
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
¿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.
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 de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat –F
## 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
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
# El resto, cerrar
iptables -A FORWARD -d 211.34.149.2 -j DROP
# El resto, cerrar
iptables -A FORWARD -d 211.34.149.3 -j DROP
# El resto, cerrar
iptables -A FORWARD -d 211.34.149.4 -j DROP
# El resto, cerrar
iptables -A FORWARD -d 211.34.149.5 -j DROP
# El resto, cerrar
iptables -A FORWARD -d 211.34.149.6 -j DROP
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
# El resto, cerrar
iptables -A FORWARD -d 211.34.149.7 -j DROP
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.
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 de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat –F
## 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
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
# El resto, cerrar
iptables -A FORWARD -d 211.34.149.5 -j DROP
Página 23
iptables -A FORWARD -s 211.34.149.7 -d 195.55.234.2 -p tcp --sport 1434 -j ACCEPT
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.
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
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.
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
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:
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:
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
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:
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 su_nombre@su-dominio.net
ftp_user proxy@su-dominio.net
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.
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:
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:
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
En el siguiente ejemplo consideramos una regla que establece acceso permitido a Squid a la Lista de Control de Acceso
denominada “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:
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.
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:
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:
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
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:
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.
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:
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.
Por defecto el parámetro httpd_accel_with_proxy viene con el valor off, es importante no olvidar cambiar este valor por
on.
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.
Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, ejecute lo siguiente:
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.
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:
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.
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:
Lo anterior hace que cualquier petición hacia el puerto 80 (servicio HTTP) hecha desde la red local hacia el exterior, se re-
direccionará hacia el puerto 8080 del servidor.
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
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.
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.
# ./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:
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 20/tcp
ftp 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:
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:
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.
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
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).
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
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,
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.
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
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 (-).
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 3
PRIVATE 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
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
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 ftp@ftp.su-sitio.com 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 ftp@ftp.su-sitio.com
MESSAGE 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:
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 Descripción
%T Hora local.
%F Espacio libre de la partición en la que está situado el path.
%C El directorio de trabajo actual.
%E La dirección de correo electrónico especificado con el comando e-mail.
%R Nombre de máquina cliente.
%L Nombre de máquina servidor.
%U Nombre de usuario proporcionado por la hora de entrada.
%M Número máximo de usuarios permitidos en la clase login.
%N Número de usuarios en la clase.
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
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:
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:
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 TRANSFERS 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:
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
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:
debería permitir que un usuario que introduzca el comando cd redhat y vaya directamente
al directorio /pub/linux/distributions/redhat.
cdpath directorio
Página 43
donde directorio es el nombre del directorio que quiera añadir al path. Por ejemplo, si usa
cdpath /pub/linux
cdpath /pub/recipes
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
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:
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
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 ON real
DELETE 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 ON real
OVERWRITE Este comando le permite decidir si los usuarios tienen el derecho a sobrescribir archivos
existentes con sus bajadas. El formato del comando es:
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 ON real
UMASK 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 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
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, masinfo@cortech.com.ar 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 wu-
ftpd 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:
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
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
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.
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
Campo Descripción
Strippre 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».
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.
Options 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.
Desc Éste es un campo libre que le permite describir qué hace el filtro.
Tabla 13.2. Campos del archivo /etc/ftpconversions
:::.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:
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.
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:
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
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.
Los permisos de estos directorios deberían configurarse con los comandos siguientes:
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.)
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 /home/ftp/lib
# ln -s ld-2.1.1.so ld-linux.so.2
# ln -s libc-2.1.1.so libc.so.6
# ln -s libnsl-2.1.1.so libnsl.so.1
# ln -s libnss_files-2.1.1.so libnss_files.so.2
# cd /home/ftp/bin
# ln -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:
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.
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:
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 /home/ftp * no
upload /home/ftp /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.
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
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 /home/ftp * no
upload /home/ftp /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.)
Página 52
chmod no guest
delete no guest
overwrite no guest
renane no guest
log transfers real inbound,outbound
passwd-check rfc822 warn
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.
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:
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:
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.
Una vez hecho esto nos preguntará el nombre de usuario y la contraseña, es decir:
Username nombre de usuario
password palabra clave
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.
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 Dá información sobre el comando especificado, correspondeinte a
? comando la máquina local
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
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
get archivo-remoto
ó
get
(remote-file) archivo-remoto
Si se quieren transferir varios archivos de la máquina remota a la local, se utiliza el comando mget. La sintaxis es:
Nota
Los nombres de los ficheros van separados por blancos y pueden incluir los
metacaracteres “*” y “?”.
put archivo-local
ó
put
(File) archivo-local
Si se quieren transferir varios archivos de la máquina local a la remota, se utiliza el comando mput. La sintaxis es:
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.
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 jose@cortech.com.ar) 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)
SendMail
Es el servidor de mail más popular de todo el mundo UNIX.
URL: www.sendmail.org
Costo: $0
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
Exim
Es muy poderoso, escalable y bien documentado.
URL: www.exim.org
Costo: $0
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,-
GLMail
Poderoso, fácil de usar y de instalar
URL: www.ntmail.co.uk
Costo: U$S 800,-
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.mi-
dominio.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.
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:
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.
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.
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
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):
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:
servidor.indeseable.com REJECT
part.com.mx REJECT
newlad.com REJECT
dmc.com.mx REJECT
propnewidea.com REJECT
lapromocion.com REJECT
hosting.com.mx REJECT
solopromos.com.mx 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
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:
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:
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:
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:
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
Página 69
Puede habilitar los servicios de manera automática e inmediata ejecutando los siguientes comandos (solo habilite aquellos que
realmente necesite):
chkconfig ipop3 on
chkconfig pop3s on
chkconfig imap on
chkconfig 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 = stream
wait = no
user = root
server = /usr/sbin/ipop3d
log_on_success += USERID
log_on_failure += USERID
disable = no
only_from = 192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.4
localhost
}
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 REJECT
propnewidea.com REJECT
lapromocion.com REJECT
hosting.com REJECT
solopromos.com REJECT
Página 70
Acto seguido se ejecuta el siguiente comando:
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:
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.
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.
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.
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.
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.
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.
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.
Como dijimos telnet esta por default en W2K. Podemos comenzar el servicio haciendo:
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. Elija 3 y haga enter. Esto permitira modificar el REGISTRY
3. Elija 7 y enter . El default es 2. Significa NTLM como describimos
4. ponga opcion 1 . Diga y …
5. ponga 0 para modificar el REGISTRY
6. S para stopear el servicio
7. 4 para recomenzar
8. 0 para salir del tlntadmn
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:
Para hacer que los cambios hechos a la configuración surtan efecto, ejecute:
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:
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
sftp usuario@servidor
Página 80