Linux Original Courseware - LX4 Advanced Network Administrator

LOC: Linux Original Courseware
Correspondiente al Curso
LX4: Advanced Network Administrator
Página 1
Tabla de Contenidos
Capítulo 1 ............................................................................................................................................................................................ 5
Introducción a iptables.................................................................................................................................................................... 5
¿Qué es un Firewall?....................................................................................................................................................................... 5
¿Qué es iptables?............................................................................................................................................................................. 8
Creando un firewall con iptables .................................................................................................................................................... 9
Proteger la propia máquina ......................................................................................................................................................... 9
Firewall de una LAN con salida a internet............................................................................................................................... 11
Firewall de una LAN con salida a internet con DMZ.............................................................................................................. 15
Firewall puro y duro entre redes............................................................................................................................................... 19
Firewall con política por defecto DROP .................................................................................................................................. 22
Depurar el funcionamiento del firewall........................................................................................................................................ 24
Capítulo 2 .......................................................................................................................................................................................... 25
Introducción a Squid ..................................................................................................................................................................... 25
Software necesario ........................................................................................................................................................................ 25
Instalación del software necesario................................................................................................................................................ 25
Antes de continuar ........................................................................................................................................................................ 26
Configuración básica. ................................................................................................................................................................... 26
¿Que puerto utilizar para Squid? Parámetro http_port............................................................................................................. 26
¿Cuánta memoria utilizar? Parámetro cache_mem.................................................................................................................. 27
¿Cuanto desea almacenar de Internet en el disco duro? Parámetro cache_dir ........................................................................ 27
Aviso de problemas con la cache - Parámetro cache_mgr....................................................................................................... 28
Acceso FTP anónimo a Servidores - Parámetro ftp_user ........................................................................................................ 28
Acceso FTP pasivo a traves de un Firewall - Parámetro ftp_passive...................................................................................... 28
Control de acceso ...................................................................................................................................................................... 28
Control de acceso - Listas......................................................................................................................................................... 28
Control de acceso - Reglas........................................................................................................................................................ 29
Aplicando Listas y Reglas de control de acceso. ..................................................................................................................... 29
Cache con aceleración............................................................................................................................................................... 30
Estableciendo el idioma por defecto............................................................................................................................................. 31
Iniciando, reiniciando y añadiendo el servicio al arranque del sistema. ..................................................................................... 31
Ajustes para el Firewall o script de Enmascaramiento de IP....................................................................................................... 32
Use Iptables en lugar de ipchains. ............................................................................................................................................ 32
Re-direccionamiento de peticiones........................................................................................................................................... 32
Script ejemplo de Enmascaramiento de IP con iptables. ......................................................................................................... 33
Capítulo 3 .......................................................................................................................................................................................... 35
Introducción a FTP........................................................................................................................................................................ 35
El ABC de FTP ............................................................................................................................................................................. 35
La relación cliente/servidor ...................................................................................................................................................... 35
¿Cómo conseguir la última versión de wu-ftpd?.......................................................................................................................... 36
Lectura de los README.......................................................................................................................................................... 36
Compilación e instalación de wu-ftpd...................................................................................................................................... 36
Configuración de wu-ftpd............................................................................................................................................................. 37
Control de acceso a través del archivo /etc/ftpaccess .............................................................................................................. 37
Configuraciones típicas............................................................................................................................................................. 49
Configuración del usuario anónimo ......................................................................................................................................... 49
Configuración del directorio FTP anónimo.............................................................................................................................. 50
Configuración de /etc/ftpaccess................................................................................................................................................ 51
Configuración del directorio /incoming ................................................................................................................................... 51
Usuarios sólo registrados y acceso mixto................................................................................................................................. 52
Página 2
Configuración de un Servidor FTP Virtual .................................................................................................................................. 53
Conclusiones ................................................................................................................................................................................. 53
Capítulo 4 .......................................................................................................................................................................................... 55
Introducción al Cliente FTP.......................................................................................................................................................... 55
Ejecución del Cliente FTP ............................................................................................................................................................ 55
Comandos del Cliente FTP ........................................................................................................................................................... 55
Salir de una sesión de FTP........................................................................................................................................................ 55
Obtener Ayuda .......................................................................................................................................................................... 55
Manipulación de Archivos y Directorios ................................................................................................................................. 56
Transferencia de Archivos ............................................................................................................................................................ 56
Tipos de Transferencia.............................................................................................................................................................. 56
Transferencia Interactiva .......................................................................................................................................................... 56
Transferencia de archivos desde la máquina Remota a la Local ............................................................................................. 57
Transferencia de archivos desde la máquina Local a la Remota ............................................................................................. 57
Capítulo 5 .......................................................................................................................................................................................... 58
Introducción a Servidores de Correo Elecrónico (e-mail) ........................................................................................................... 58
Funciones de los mail servers ....................................................................................................................................................... 58
Relay.......................................................................................................................................................................................... 58
Recolección ............................................................................................................................................................................... 58
Spam y Virus................................................................................................................................................................................. 58
Servidores de e-mail conocidos .................................................................................................................................................... 59
QMail ........................................................................................................................................................................................ 59
SendMail ................................................................................................................................................................................... 59
Postfix........................................................................................................................................................................................ 60
Exim .......................................................................................................................................................................................... 60
SuSE Linux eMail Server 3.1 ................................................................................................................................................... 61
GLMail ...................................................................................................................................................................................... 61
Capítulo 6 .......................................................................................................................................................................................... 62
Introducción a SendMail............................................................................................................................................................... 62
Requisitos previos ..................................................................................................................................................................... 62
Resultados a obtener ................................................................................................................................................................. 62
Requerimientos mínimos .............................................................................................................................................................. 62
Procedimientos.............................................................................................................................................................................. 63
Preparativos............................................................................................................................................................................... 63
Verificando parámetros de red.................................................................................................................................................. 63
Confirmando la instalación de Sendmail.................................................................................................................................. 64
Configurando Sendmail ................................................................................................................................................................ 64
Habilitando los servicios POP3 e IMAP ...................................................................................................................................... 69
¿Que hacer con el Spam?.............................................................................................................................................................. 70
El Servidor de Nombres (DNS).................................................................................................................................................... 71
Configuración de los clientes de correo ....................................................................................................................................... 72
Capítulo 7 .......................................................................................................................................................................................... 73
Introducción a Horde (WebMail) ................................................................................................................................................. 73
¿Qué es Horde? ......................................................................................................................................................................... 73
¿Qué es IMP? ............................................................................................................................................................................ 73
¿Qué es Turba?.......................................................................................................................................................................... 73
¿Qué es Kronolith? ................................................................................................................................................................... 73
¿Qué es Jonah?.......................................................................................................................................................................... 73
¿Qué es WHUPS? ..................................................................................................................................................................... 73
¿Qué es Chora? ......................................................................................................................................................................... 73
¿Qué es Gollem? ....................................................................................................................................................................... 73
Solamente quiero WebMail. ¿Por qué necesito Horde?............................................................................................................... 73
¿Cuánto cuesta Horde? ............................................................................................................................................................. 74
¿En qué plataformas funciona Horde? ..................................................................................................................................... 74
¿Horde funciona en Windows 95 o en NT/2K/XP?................................................................................................................. 74
Página 3
Capítulo 8 .......................................................................................................................................................................................... 75
Introducción a Administración Remota........................................................................................................................................ 75
Diferentes tipos de Administración Remota ................................................................................................................................ 75
Control Remoto......................................................................................................................................................................... 75
Sesión Remota........................................................................................................................................................................... 75
Acceso Remoto ......................................................................................................................................................................... 75
Direcciones Web relacionadas...................................................................................................................................................... 76
Capítulo 9 .......................................................................................................................................................................................... 77
Introducción a TelNet ................................................................................................................................................................... 77
Telnet en Linux ............................................................................................................................................................................. 77
Telnet en Windows 2000 .............................................................................................................................................................. 77
Capítulo 10 ........................................................................................................................................................................................ 79
Introducción a SSH ....................................................................................................................................................................... 79
Software requerido........................................................................................................................................................................ 79
Archivos de configuración............................................................................................................................................................ 79
Procedimientos.............................................................................................................................................................................. 79
Parámetro ListenAddress.......................................................................................................................................................... 79
Parámetro PermitRootLogin..................................................................................................................................................... 79
Parámetro X11Forwarding ....................................................................................................................................................... 79
Aplicando los cambios.................................................................................................................................................................. 80
Probando OpenSSH. ..................................................................................................................................................................... 80
Acceso por shell. ....................................................................................................................................................................... 80
Acceso por SFTP ...................................................................................................................................................................... 80
Página 4
Capítulo 1
Introducción a iptables
En este manual se muestran las habituales arquitecturas de redes con firewall y la forma de montar iptables para cada caso,
con distintas opciones para cada ejemplo.
¿Qué es un Firewall?
Un firewall es un dispositivo que filtra el tráfico entre redes, como mínimo dos. El firewall puede ser un dispositivo físico o un
software sobre un sistema operativo. En general debemos verlo como una caja con 2 (dos) o más interfaces de red en la que se
establecen una reglas de filtrado con las que se decide si una conexión determinada puede establecerse o no. Incluso puede ir
más allá y realizar modificaciones sobre las comunicaciones, como el NAT.
Esa sería la definición genérica, hoy en día un firewall es un hardware específico con un sistema operativo o una BIOS que
filtra el tráfico TCP/UDP/ICMP/IP y decide si un paquete pasa, se modifica, se convierte o se descarta. Para que un firewall
entre redes funcione como tal debe tener al menos dos tarjetas de red. Esta sería la tipología clásica de un firewall:
Figura 1: Esquema de firewall típico entre red local e internet
Esquema típico de firewall para proteger una red local conectada a internet a través de un router. El firewall debe colocarse
entre el router (con un único cable) y la red local (conectado al switch o al hub de la LAN)
Dependiendo de las necesidades de cada red, puede ponerse uno o más firewalls para establecer distintos perímetros de
seguridad en torno a un sistema. Es frecuente también que se necesite exponer algún servidor a internet (como es el caso de un
servidor web, un servidor de correo, etc.), y en esos casos obviamente en principio se debe aceptar cualquier conexión a ellos.
Lo que se recomienda en esa situación es situar ese servidor en lugar aparte de la red, el que denominamos DMZ o zona
desmilitarizada. El firewall tiene entonces tres entradas:
Figura 2: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos
En la zona desmilitarizada se pueden poner tantos servidores como se necesiten. Con esta arquitectura, permitimos que el
servidor sea accesible desde internet de tal forma que si es atacado y se gana acceso a él, la red local sigue protegida por el
Página 5
firewall. Esta estructura de DMZ puede hacerse también con un doble firewall (aunque como se ve se puede usar un único
dispositivo con al menos tres interfaces de red). Sería un esquema como este:
Figura 3: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos creado con doble firewall
(perímetro)
Los firewalls se pueden usar en cualquier red. Es habitual tenerlos como protección de internet en las empresas, aunque ahí
también suelen tener una doble función: controlar los accesos externos hacia dentro y también los internos hacia el exterior;
esto último se hace con el firewall o frecuentemente con un proxy (que también utilizan reglas, aunque de más alto nivel).
También, en empresas de hosting con muchos servidores, lo normal es encontrarnos uno o más firewalls ya sea filtrando toda la
instalación o parte de ella:
Figura 4: Esquema de firewall entre redes, en la que solo se filtra y no se hace NAT
Página 6
Sea el tipo de firewall que sea, generalmente no tendrá mas que un conjunto de reglas en las que se examina el origen y destino
de los paquetes del protocolo TCP/IP. En cuanto a protocolos es probable que sean capaces de filtrar muchos tipos de ellos, no
solo los TCP, también los UDP, los ICMP, los GRE y otros protocolos vinculados a vpns. Este podría ser (en pseudo-
lenguaje) un conjunto de reglas de un firewall del primer gráfico:
Política por defecto ACEPTAR.

Todo lo que venga de la red local al firewall ACEPTAR
Todo lo que venga de la ip de mi casa al puerto tcp 22 ACEPTAR
Todo lo que venga de la ip de casa del jefe al puerto tcp 1723 ACEPTAR
Todo lo que venga de hora.rediris.es al puerto udo 123 ACEPTAR
Todo lo que venga de la red local y vaya al exterior ENMASCARAR
Todo lo que venga del exterior al puerto tcp 1 al 1024 DENEGAR
Todo lo que venga del exterior al puerto tcp 3389 DENEGAR
Todo lo que venga del exterior al puerto udp 1 al 1024 DENEGAR
En definitiva lo que se hace es:

• Habilita el acceso a puertos de administración a determinadas IPs privilegiadas
• Enmascara el trafico de la red local hacia el exterior (NAT, una petición de un pc de la LAN sale al exterior con la IP
pública), para poder salir a internet
• Deniega el acceso desde el exterior a puertos de administración y a todo lo que este entre 1 y 1024.
Hay dos maneras de implementar un firewall:

1) Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall se acepta y solo se denegará lo que
se diga explícitamente.
2) Política por defecto DENEGAR: todo esta denegado, y solo se permitirá pasar por el firewall aquellos que se permita
explícitamente.
Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya que simplemente nos tenemos que
preocupar de proteger aquellos puertos o direcciones que sabemos que nos interesa; el resto no importa tanto y se deja pasar.
Por ejemplo, si queremos proteger una máquina linux, podemos hacer un netstat -ln (o netstat -an, o netstat –
puta | grep LISTEN), saber que puertos están abiertos, poner reglas para proteger esos puertos y ya está. ¿Para qué vamos a
proteger un puerto que realmente nunca se va a abrir?
El único problema que podemos tener es que no controlemos que es lo que esta abierto, o que en un momento dado se instale un
software nuevo que abra un puerto determinado, o que no sepamos que determinados paquetes ICMP son peligrosos. Si la
política por defecto es ACEPTAR y no se protege explícitamente, podemos poner en riesgo la PC o Servidor que queremos
proteger.
En cambio, si la política por defecto es DENEGAR, a no ser que lo permitamos explícitamente, el firewall se convierte en un
auténtico MURO infranqueable. El problema es que es mucho más difícil preparar un firewall así, y hay que tener muy claro
como funciona el sistema (sea iptables o el que sea) y que es lo que se tiene que abrir sin caer en la tentación de empezar a
meter reglas super-permisivas.
Esta configuración de firewall es la recomendada, aunque no es aconsejable usarla si no se domina mínimamente el sistema.
Uno de los objetos principales de este documento es mostrar la forma de crear este tipo de firewalls.
Importante
El orden en el que se ponen las reglas de firewall es determinante. Normalmente
cuando hay que decidir que se hace con un paquete se va comparando con cada
regla del firewall hasta que se encuentra una que le afecta (match), y se hace lo que
dicte esta regla (aceptar o denegar); después de eso NO SE MIRARÁN MÁS
REGLAS para ese paquete. ¿Cuál es el peligro? Si ponemos reglas muy permisivas
entre las primeras del firewall, puede que las siguientes no se apliquen y no sirvan
de nada.
Página 7
¿Qué es iptables?
IPtables es un sistema de firewall vinculado al kernel de linux que se ha extendido enormemente a partir del kernel 2.4 de este
sistema operativo. Al igual que el anterior sistema ipchains, un firewall de iptables no es como un servidor que lo
iniciamos o detenemos o que se pueda caer por un error de programación (aunque ha tenido alguna vulnerabilidad que permite
DoS, pero nunca tendrá tanto peligro como las aplicaciones que escuchan en determinado puerto TCP): iptables esta
integrado con el kernel, es parte del sistema operativo. ¿Cómo se pone en marcha? Realmente lo que se hace es aplicar reglas.
Para ellos se ejecuta el comando iptables, con el que añadimos, borramos, o creamos reglas. Por ello un firewall de
iptables no es sino un simple script de shell en el que se van ejecutando las reglas de firewall.
Nota
Se puede implementar un script de inicio en /etc/rc.d/init.d (ó
/etc/init.d) con el que hagamos que iptables se "inicie o pare" como un
servicio más. Lo podemos hacer nosotros o es probable que venga en la
distribución (como en RedHat por ejemplo). También se pueden salvar las reglas
aplicadas con el comando iptables-save en un fichero y gestionar ese fichero
con una aplicación o front-end desde la X o desde webmin.
Si tenemos una máquina linux con soporte para iptables, tiene reglas aplicadas y empiezan a llegar/salir/pasar paquetes. Por
ahora no es necesario que tengamos en cuenta cuantas placas de red hay, que direcciones IP tiene la máquina y olvidemos si el
paquete entra o sale. Las reglas de firewall están a nivel de kernel, y al kernel lo que le llega es un paquete y tiene que decidir
que hacer con él. El kernel lo que hace es, dependiendo si el paquete es para la propia máquina o para otra máquina, consultar
las reglas de firewall y decidir que hacer con el paquete según mande el firewall. Este es el camino que seguiría un paquete en
el kernel:
Figura 5: Cuando un paquete u otra comunicación llegan al kernel con iptables se sigue este camino
Como se ve en el gráfico, básicamente se mira si el paquete esta destinado a la propia máquina o si va a otra. Para los paquetes
(o datagramas, según el protocolo) que van a la propia máquina se aplican las reglas INPUT y OUTPUT, y para filtrar paquetes
que van a otras redes o máquinas se aplican simplemente reglas FORWARD.
INPUT, OUTPUT y FORWARD son los tres tipos de reglas de filtrado.

Antes de aplicar esas reglas es posible aplicar reglas de NAT: estas se usan para hacer redirecciones de puertos o cambios en las
IPs de origen y destino. Veremos ejemplos más adelante.
E incluso antes de las reglas de NAT se pueden meter reglas de tipo MANGLE, destinadas a modificar los paquetes; son reglas
poco conocidas y es probable que no las usen.
Por tanto tenemos tres tipos de reglas en iptables:
• MANGLE
• NAT: reglas PREROUTING, POSTROUTING
• FILTER: reglas INPUT, OUTPUT, FORWARD.
Página 8
Creando un firewall con iptables
En este tutorial se ha intentado dar una breve introducción sobre lo que es un firewall, sus tipologías básicas y en concreto se
presenta el sistema iptables. Ahora veremos configuraciones de firewall con iptables, empezando desde la más básica a
las más complejas, en las que se establece la denegación como política por defecto.
Nota
Se recomienda encarecidamente ir practicando estas reglas en alguna máquina
linux disponible, y especialmente hacer uso de la herramienta iptraf para
depurar y comprobar el funcionamiento de iptables. Con iptraf podemos
comprobar si las conexiones TCP/IP se llegan a establecer o no.
Una conexión TCP/IP empieza con el three-way-handshake:

• La maquina que desea conectarse a otra envía un paquete con flag SYN
• Si la otra maquina acepta, envía un SYN/ACK
• Entonces la máquina establece la conexión.
Si el firewall esta denegando la conexión, con iptraf veremos que la máquina origen sólo manda paquetes con el flag SYN, y
que del otro lado no sale nada. Saber usar iptraf nos ayudará mucho.
Proteger la propia máquina

Muy bien, tenemos una máquina linux conectada a internet y queremos protegerla con su propio firewall. Lo único que tenemos
que hacer es crear un script de shell en el que se van aplicando las reglas.
Los scripts de iptables pueden tener este aspecto:
Saludo a la afición (echo)

Borrado de las reglas aplicadas actualmente (flush)
Aplicación de políticas por defecto para INPUT, OUPUT, FORWARD
Listado de reglas iptables.
Ojo con el orden de las reglas
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para proteger la propia máquina
echo -n Aplicando Reglas de Firewall...
## FLUSH de reglas
iptables –F
iptables –X
iptables –Z
iptables -t nat –F
## Establecemos politica por defecto

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

iptables -A INPUT -s 195.65.34.234 -j ACCEPT
Página 9
# A un colega le dejamos entrar al mysql para que mantenga la BBDD
iptables -A INPUT -s 231.45.134.23 -p tcp --dport 3306 -j ACCEPT
# A un diseñador le dejamos usar el FTP

iptables -A INPUT -s 80.37.45.194 -p tcp -dport 20:21 -j ACCEPT
# El puerto 80 de www debe estar abierto, es un servidor web.

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Y el resto, lo cerramos
iptables -A INPUT -p tcp --dport 20:21 -j DROP
iptables -A INPUT -p tcp --dport 22 -j DROP
echo " OK . Verifique que lo que se aplica con: iptables -L –n "

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

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Cerramos rango de los puertos privilegiados. Cuidado con este tipo de

# barreras, antes hay que abrir a los que si tienen acceso.
iptables -A INPUT -p tcp --dport 1:1024 -j DROP
iptables -A INPUT -p udp --dport 1:1024 -j DROP
# Y el resto, lo cerramos
iptables -A INPUT -p udp --dport 10000 -j DROP

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

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

## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN
# Al firewall tenemos acceso desde la red local

iptables -A INPUT -s 192.168.10.0/24 -i eth1 -j ACCEPT
# Ahora hacemos enmascaramiento de la red local

# y activamos el BIT DE FORWARDING (imprescindible!!!!!)
iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE
# Con esto permitimos hacer forward de paquetes en el firewall, o sea

# que otras máquinas puedan salir a traves del firewall.
Página 11
echo 1 > /proc/sys/net/ipv4/ip_forward
## Y ahora cerramos los accesos indeseados del exterior:

# Nota: 0.0.0.0/0 significa: cualquier red
# Cerramos el rango de puerto bien conocido
iptables -A INPUT -s 0.0.0.0/0 -p tcp -dport 1:1024 -j DROP
iptables -A INPUT -s 0.0.0.0/0 -p udp -dport 1:1024 -j DROP
# Cerramos un puerto de gestión: webmin

iptables -A INPUT -s 0.0.0.0/0 -p tcp -dport 10000 -j DROP
echo " OK . Verifique que lo que se aplica con: iptables -L -n"

# Fin del script
Pero como somos muy malvados queremos que los empleados solamente puedan navegar por internet, denegando el acceso a
Kazaa o edonkey. Esta sería una configuración simple pero efectiva. Reemplazamos en el script anterior lo siguiente:
# Hasta aquí el script es igual al ejemplo anterior

## Ahora con regla FORWARD filtramos el acceso de la red local

## al exterior. Como se explica antes, a los paquetes que no van dirigidos al
## propio firewall se les aplican reglas de FORWARD
# Aceptamos que vayan a puertos 80
iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -p tcp --dport 80 -j ACCEPT
# Aceptamos que vayan a puertos https

# Aceptamos que consulten los DNS

iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -p udp --dport 53 -j ACCEPT
# Y denegamos el resto. Si se necesita alguno, ya avisaran

iptables -A FORWARD -s 192.168.10.0/24 -i eth1 -j DROP

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

#!/bin/sh
## con servicios abiertos de puerto 25, 110, y 1723
Página 12
## FLUSH de reglas
iptables –F
iptables –X
iptables –Z

iptables -A INPUT -i lo -j ACCEPT

## Abrimos el acceso a puertos de correo

# Abrimos el puerto 25, hay que configurar bien el relay del servidor SMTP
iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport 25 -j ACCEPT
# Abrimos el pop3
# Y abrimos el puerto pptpd para la ip del adsl de casa del jefe







iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p tcp -dport 1:1024 -j DROP
iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p udp -dport 1:1024 -j DROP

iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p tcp --dport 10000 -j DROP
Página 13
# Y cerramos el puerto del servicio PPTPD, solo abierto para el jefe.

# Fin del script
¡Más difícil todavía!

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

## REDIRECCIONES
# Todo lo que venga por el exterior y vaya al puerto 80 lo redirigimos
# a una maquina interna
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.10.12:80
# Los accesos de un ip determinada a Terminal server se redirigen e esa

# maquina
iptables -t nat -A PREROUTING -s 221.23.124.181 -i eth0 -p tcp --dport 3389 -j DNAT --to
192.168.10.12:3389

iptables -A INPUT -i lo -j ACCEPT

## Abrimos el acceso a puertos de correo

# Abrimos el puerto 25, hay que configurar bien el relay del servidor SMTP
# Abrimos el pop3
# Y abrimos el puerto pptpd para la ip del adsl de casa del jefe
Página 14







iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p tcp -dport 1:1024 -j DROP
iptables -A INPUT -s 0.0.0.0/0 -i eth0 -p udp -dport 1:1024 -j DROP

# Y cerramos el puerto del servicio PPTPD, solo abierto para el jefe.


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

Bueno, esto se va complicando. Imaginemos que tenemos una red parecida a la anterior pero ahora hacemos las cosas bien y
colocamos ese servidor IIS en una DMZ:
Página 15
Figura 7: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos.
En este tipo de firewall hay que permitir:

• Acceso de la red local a internet.
• Acceso público al puerto TCP/80 y TCP/443 del servidor de la DMZ
• Acceso del servidor de la DMZ a una BBDD de la LAN
• Obviamente bloquear el resto de acceso de la DMZ hacia la LAN.
¿Qué tipo de reglas son las que hay que usar para filtrar el tráfico entre la DMZ y la LAN? Solo pueden ser las FORWARD, ya
que estamos filtrando entre distintas redes, no son paquetes destinados al propio firewall.
#!/bin/sh
## Ejemplo de script para firewall entre red-local e internet con DMZ
## FLUSH de reglas
iptables –F
iptables –X
iptables –Z

# Todo lo que venga por el exterior y vaya al puerto 80 lo redirigimos
# a una maquina interna
# Los accesos de un ip determinada HTTPS se redirigen e esa

# maquina


Página 16
# Ahora hacemos enmascaramiento de la red local y de la DMZ
# para que puedan salir haca fuera

## Permitimos el paso de la DMZ a una BBDD de la LAN:

iptables -A FORWARD -s 192.168.3.2 -d 192.168.10.5 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -s 192.168.10.5 -d 192.168.3.2 -p tcp --sport 5432 -j ACCEPT
## permitimos abrir el Terminal server de la DMZ desde la LAN

iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.3.2 -p tcp --sport 1024:65535 --dport
3389 -j ACCEPT
# … hay que hacerlo en uno y otro sentido …

iptables -A FORWARD -s 192.168.3.2 -d 192.168.10.0/24 -p tcp --sport 3389 --dport
1024:65535 -j ACCEPT
# … por que luego:

# Cerramos el acceso de la DMZ a la LAN
iptables -A FORWARD -s 192.168.3.0/24 -d 192.168.10.0/24 -j DROP
## Cerramos el acceso de la DMZ al propio firewall

iptables -A INPUT -s 192.168.3.0/24 -i eth2 -j DROP




# Fin del script
Si las máquinas de la DMZ tienen una IP pública hay que tener muchísimo cuidado de no permitir el FORWARD por defecto.
Si en la DMZ hay IP pública NO ES NECESARIO HACER REDIRECCIONES de puerto, sino que basta con rutar los
paquetes para llegar hasta la DMZ. Este tipo de necesidades surgen cuando por ejemplo tenemos dos máquinas con servidor
web (un Apache y un IIS); ¿A cuál de las dos le redirigimos el puerto 80? No hay manera de saberlo (con servidores virtuales
tampoco), por eso se deben asignar IPs públicas o en su defecto usar puertos distintos.
Por tanto hay que proteger convenientemente toda la DMZ. Tampoco haría falta enmascarar la salida hacia el exterior de la
DMZ, si tiene una IP pública ya tiene una pata puesta en internet; obviamente hay que decirle al router como llegar hasta esa
IP pública. Así podría ser esta red:
Página 17
Figura 8: Esquema de firewall entre red local e internet con zona DMZ
para servidores expuestos usando IPs públicas
Y este podría ser el script para un firewall adecuado:
#!/bin/sh
## Ejemplo de script para firewall entre red-local e internet con DMZ
## pero con IPs públicas.
## FLUSH de reglas
iptables –F
iptables –X
iptables –Z


# Ahora hacemos enmascaramiento de la red local y de la DMZ para que puedan

# salir haca fuera y activamos el BIT DE FORWARDING (imprescindible!!!!!)

## Permitimos el acceso desde el exterior a los puertos 80 y 443 de DMZ

iptables -A FORWARD -d 212.194.89.152 -p tcp -dport 80 -j ACCEPT
Página 18
iptables -A FORWARD -d 212.194.89.152 -p tcp -dport 443 -j ACCEPT
iptables -A FORWARD -d 212.194.89.150/30 -j DROP
## Permitimos el paso de la DMZ a una BBDD de la LAN:

# en el otro sentido lo mismo

## permitimos abrir el Terminal server de la DMZ desde la LAN

iptables -A FORWARD -s 192.168.10.0/24 -d 212.194.89.152 -p tcp --sport 1024:65535 --
dport 3389 -j ACCEPT
# … hay que hacerlo en uno y otro sentido …

iptables -A FORWARD -s 212.194.89.152 -d 192.168.10.0/24 -p tcp --sport 3389 --dport
1024:65535 -j ACCEPT
# … por que luego:

# Cerramos el acceso de la DMZ a la LAN
iptables -A FORWARD -s 212.194.89.152 -d 192.168.10.0/24 -j DROP
## Cerramos el acceso de la DMZ al propio firewall

iptables -A INPUT -s 212.194.89.152 -i eth2 -j DROP



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

En este caso olvidémonos de redes locales y de NAT. Aquí solo tendremos reglas de filtrado INPUT y FORWARD. Pongamos
que tenemos el siguiente escenario:
Página 19
Figura 9: Esquema de firewall entre redes, en la que solo se filtra y no se hace NAT
En el firewall debemos indicar una serie de reglas para proteger los equipos que están al otro lado de este dispositivo, todos
ellos de la red 211.34.149.0/24. Cada uno de ellos da un servicio determinado, y puede estar gestionado desde distintas IPs,
lo que significa que habrá que dar acceso a determinados puertos de gestión (22, 3389, etc.).
Este podría ser el aspecto del script del firewall:
#!/bin/sh
## Ejemplo de script para firewall entre redes.
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z

# A nuestro firewall tenemos acceso total desde la nuestra IP
# Para el resto no hay acceso al firewall

iptables -A INPUT -s 0.0.0.0/0 -j DROP
Página 20
## Ahora podemos ir metiendo las reglas para cada servidor
## Como serán paquetes con destino a otras máquinas se aplica FORWARD
## Servidor WEB 211.34.149.2
# Acceso a puerto 80
iptables -A FORWARD -d 211.34.149.2 -p tcp --dport 80 -j ACCEPT
# Acceso a nuestra ip para gestionarlo

# El resto, cerrar
iptables -A FORWARD -d 211.34.149.2 -j DROP
## Servidor MAIL 211.34.149.3

# Acceso a puerto 25, 110 y 143
# Acceso a gestion SNMP

iptables -A FORWARD -s 210.195.55.15 -d 211.34.149.3 -p udp --dport 169 -j ACCEPT

# El resto, cerrar
## Servidor IRC 211.34.149.4

# Acceso a puertos IRC
iptables -A FORWARD -d 211.34.149.4 -p tcp --dport 6666:6668 -j ACCEPT

# El resto, cerrar
## Servidor NEWS 211.34.149.5

# Acceso a puerto news
iptables -A FORWARD -d 211.34.149.5 -p tcp --dport news -j ACCEPT

# El resto, cerrar
## Servidor B2B 211.34.149.6

# Acceso a una ip para gestionarlo

# El resto, cerrar
## Servidor CITRIX 211.34.149.7

Página 21
# acceso a otro puerto quiza de BBDD

# El resto, cerrar

# Fin del script
Con esta firewall y sobretodo gracias a las reglas de DROP que metemos tras especificar lo que dejamos abiertos, protegeremos
de manera eficaz todos lo puertos abiertos de las máquinas.
Firewall con política por defecto DROP

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

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# A nuestro firewall tenemos acceso total desde la nuestra IP
iptables -A OUTPUT -d 210.195.55.15 -j ACCEPT
# Para el resto no hay acceso al firewall

# En principio esta de más, pero si rebajamos los permisos temporalmente
# nos cubre las espaldas
iptables -A INPUT -s 0.0.0.0/0 -j DROP
## Ahora podemos ir metiendo las reglas para cada servidor

## Como serán paquetes con destino a otras máquinas se aplica FORWARD
## Servidor WEB 211.34.149.2
iptables -A FORWARD -s 211.34.149.2 -p tcp --sport 80 -j ACCEPT
Página 22
## Servidor MAIL 211.34.149.3

# Acceso a puerto 25, 110 y 143
# Acceso a gestion SNMP

iptables -A FORWARD -s 211.34.149.3 -d 210.195.55.15 -p udp --sport 169 -j ACCEPT

## Servidor IRC 211.34.149.4

# Acceso a puertos IRC
iptables -A FORWARD -d 211.34.149.4 -p tcp --dport 6666:6668 -j ACCEPT
iptables -A FORWARD -s 211.34.149.4 -p tcp --sport 6666:6668 -j ACCEPT

## Servidor NEWS 211.34.149.5

# Acceso a puerto news
iptables -A FORWARD -d 211.34.149.5 -p tcp --dport news -j ACCEPT
iptables -A FORWARD -s 211.34.149.5 -p tcp --sport news -j ACCEPT

# El resto, cerrar
## Servidor B2B 211.34.149.6


## Servidor CITRIX 211.34.149.7



Página 23

iptables -A FORWARD -s 211.34.149.7 -d 195.55.234.2 -p udp --sport 1433 -j ACCEPT

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

Programas útiles:
• iptraf Sin duda alguna uno de los programas más prácticos para depurar el firewall es iptables, ya que con el
podemos observar si la conexiones se establecen o no; es un programa de consola que es aconsejable controlar
ya que muestra en tiempo real el tráfico que atraviesa nuestra máquina con todo lujo de detalles: origen/destino
de IPs y puertos, tráfico total o tráfico total según la interfaz de red, etc… Si vemos muchas conexiones
simultáneas y nos perdemos, existe la posibilidad de aplicar filtros para captar sólo aquello que nos interesa.
• nmap La herramienta para escanear puertos por excelencia. Es una herramienta de consola rápida, efectiva y con
multitud de opciones. Podemos usarla desde máquinas ajenas a nuestra red para comprobar si realmente el
firewall esta filtrando correctamente y en cierta manera para hacernos una idea de que "visión" pueden tener los
hackers de nuestro sistema.
• shell En el propio script del firewall podemos añadir algunas opciones para descubrir fallos de sintaxis en las reglas.
Claro, imaginemos que tenemos un firewall de 40 líneas y una de ellas falla cuando ejecutamos el script. ¿Cuál
es? Es probable que el mensaje de error no aclare lo suficiente, por eso se puede añadir algo así al final de cada
regla:
...
iptables -A INPUT -s 195.55.234.2 -j ACCEPT && echo " regla-21 ok"
iptables -A INPUT -s 213.62.89.145 -j ACCEPT && echo " regla-22 ok"
...
Si la regla se ejecuta bien mostrará el mensajito de ok. Otra opción sería ir eliminando o comentando reglas
hasta dar con la regla que tiene la sintaxis incorrecta. Cabe reseñar que puede fallar una regla, pero a partir de
ella el resto se ejecutan con normalidad.
Página 24
Capítulo 2
Introducción a Squid
Squid es el software para servidor Proxy más popular y extendido
entre los sistemas operativos basados sobre UNIX®. Es muy
confiable, robusto y versátil. Al ser software libre, además de
estar disponible el código fuente, está libre del pago de costosas
licencias por uso o con restricción a un uso con determinado
número de usuarios.
Entre otras cosas, Squid puede hacer Proxy y cache con los
protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL,
cache transparente, WWCP, aceleración HTTP, cache de
consultas DNS y otras muchas más como filtración de contenido
y control de acceso por IP y por usuario.
Software necesario
Para poder llevar a cabo los procedimientos descritos en este capítulo y documentos relacionados, usted necesitará tener
instalado al menos lo siguiente:
• squid-2.4.STABLE1
• iptables-1.2.4
• kernel-2.4.18-24
• Todos los parches de seguridad disponibles para la versión de Red Hat que esté utilizando.
Tómese en consideración que, de ser posible, se debe utilizar siempre las versiones estables más recientes de todo el software
que vaya a instalar al realizar los procedimientos descritos en este capítulo, a fin de contar con los parches de seguridad
necesarios. Ninguna versión de Squid anterior a la 2.4.STABLE1 se considera como apropiada debido a fallas de seguridad de
gran importancia, y ningún administrador competente utilizaría una versión inferior a la 2.4.STABLE1. Por favor visite el sito
Web de su distribución predilecta para estar al tanto de cualquier aviso de actualizaciones de seguridad.
Para Red Hat Linux 7.2, 7.3, 8.0 y 9 hay paquetería de actualización en los siguientes enlaces:
• ftp://updates.redhat.com/7.2/en/os/i386/, si su distribución está basada en Red Hat™ 7.2
• ftp://updates.redhat.com/9/en/os/i386/, si su distribución está basada en Red Hat™ 9
Instalación del software necesario.

Regularmente Squid no se instala de manera predeterminada a menos que especifique o contrario durante la instalación del
sistema operativo, sin embargo viene incluido en casi todas las distribuciones actuales. El procedimiento de instalación es
exactamente el mismo que con cualquier otro software:
mount /mnt/cdrom/
rpm -Uvh /mnt/cdrom/*/RPMS/squid-*.i386.rpm
eject
Iptables se utilizará para generar las reglas necesarias para el guión de Enmascaramiento de IP. Se instala por defecto en todas
las distribuciones actuales que utilicen kernel-2.4.
Página 25
Nota
Es importante tener actualizado el kernel por diversas cuestiones de seguridad.
No es recomendable utilizar versiones del kernel anteriores a la 2.4.18.
Para referencia de cómo instalar paquetes RPM, y cómo actualizar el kernel, vea
el LOC 1-2-3, Capítulos 4 y 5.
Antes de continuar
Tenga en cuenta que este manual ha sido comprobado varias veces y ha funcionado en todos los casos y si algo no funciona
solo significa que usted no lo leyó a detalle y no siguió correctamente las indicaciones. Evite dejar espacios vacíos en lugares
indebidos.
El siguiente es un ejemplo de como no debe des-comentarse un parámetro.
# Opción incorrectamente des-comentada

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

http_access 3128
Configuración básica.
Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá trabajar sobre este utilizando su
editor de texto preferido. Existen un gran número de parámetros, de los cuales recomendamos configurar los siguientes:
• http_port
• cache_mem
• cache_dir
• ftp_user
• ftp_passive
• Al menos una Lista de Control de Acceso
• Al menos una Regla de Control de Acceso
• httpd_accel_host
• httpd_accel_port
• httpd_accel_with_proxy
¿Que puerto utilizar para Squid? Parámetro http_port

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

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

# Default: http_port 3128
http_port 192.168.1.254:3128
http_port 192.168.1.254:8080
¿Cuánta memoria utilizar? Parámetro cache_mem

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

Este parámetro se utiliza para establecer que tamaño se desea que tenga el cache en el disco duro para Squid. Para entender esto
un poco mejor, responda a esta pregunta: ¿Cuánto desea almacenar de Internet en el disco duro? Por defecto Squid utilizará un
cache de 100 MB, de modo tal que encontrará la siguiente línea:
cache_dir ufs /var/spool/squid 100 16 256
Se puede incrementar el tamaño del cache hasta donde lo desee el administrador. Mientras más grande el cache, más objetos de
almacenarán en éste y por lo tanto se utilizará menos el ancho de banda. La siguiente línea establece un cache de 700 MB:
cache_dir ufs /var/spool/squid 700 16 256
Los números 16 y 256 significan que el directorio del cache contendrá 16 subdirectorios con 256 niveles cada uno. No
modifique esto números, no hay necesidad de hacerlo.
Nota
Es muy importante considerar que si se especifica un determinado tamaño de
cache y este excede al espacio real disponible en el disco duro, Squid se
bloqueará inevitablemente. Sea cauteloso con el tamaño de cache especificado.
Página 27
Aviso de problemas con la cache - Parámetro cache_mgr.
Por defecto, si algo ocurre con el Cache, como por ejemplo que muera el proceso, se enviará un mensaje de aviso a la cuenta
webmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente.
cache_mgr su_nombre@su-dominio.net
Acceso FTP anónimo a Servidores - Parámetro ftp_user

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

Si se tiene un muro contrafuegos que no permite acceder a servidores FTP más que de modo pasivo, debe habilitarse
ftp_passive con el valor on.
ftp_passive on
Control de acceso
Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas maquinas en particular. A cada lista se le
asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid. Procedamos a entender como definir unas
y otras.
Control de acceso - Listas

Regularmente una lista de control de acceso se establece siguiendo la siguiente sintaxis:
acl [nombre de la lista] src [lo que compone a la lista]
Si uno desea establecer una lista de control de acceso que defina sin mayor trabajo adicional a toda la red local definiendo la IP
que corresponde a la red y la máscara de la sub-red. Por ejemplo, si se tienen una red donde las máquinas tienen direcciones IP
192.168.1.n con máscara de sub-red 255.255.255.0, podemos utilizar lo siguiente:
acl miredlocal src 192.168.1.0/255.255.255.0
También puede definirse una Lista de Control de Acceso invocando un fichero localizado en cualquier parte del disco duro, y
en el cual se en cuenta una lista de direcciones IP. Ejemplo:
acl permitidos src "/etc/squid/permitidos"
El fichero /etc/squid/permitidos contendría algo como siguiente:
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.15
192.168.1.16
192.168.1.20
192.168.1.40
Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las
direcciones IP incluidas en el fichero /etc/squid/permitidos.
Página 28
Control de acceso - Reglas
Estas definen si se permite o no el acceso a Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección
de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda:
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
La sintaxis básica es la siguiente:
http_access [deny o allow] [lista de control de acceso]
En el siguiente ejemplo consideramos una regla que establece acceso permitido a Squid a la Lista de Control de Acceso
denominada “permitidos”:
http_access allow permitidos
También pueden definirse reglas valiéndose de la expresión “!”, la cual significa excepción. Pueden definirse, por ejemplo, dos
listas de control de acceso, una denominada lista1 y otra denominada lista2, en la misma regla de control de acceso, en donde se
asigna una expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo que comprenda lista1 excepto
aquello que comprenda lista2:
http_access allow lista1 !lista2
Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso, y
otro grupo dentro de la misma red al que se debe denegar el acceso.
Aplicando Listas y Reglas de control de acceso.

Una vez comprendido el funcionamiento de la Listas y las Reglas de Control de Acceso, procederemos a determinar cuales
utilizar para nuestra configuración.
Caso 1
Considerando como ejemplo que se dispone de una red 192.168.1.0/255.255.255.0, si se desea definir toda la red local,
utilizaremos la siguiente línea en la sección de Listas de Control de Acceso:
acl todalared src 192.168.1.0/255.255.255.0
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:
# Recommended minimum configuration:

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl todalared src 192.168.1.0/255.255.255.0
A continuación procedemos a aplicar la regla de control de acceso:
http_access allow todalared
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:
#
http_access allow localhost
http_access allow todalared
http_access deny all
Página 29
La regla http_access allow todalared permite el acceso a Squid a la Lista de Control de Acceso denominada
todalared, la cual está conformada por 192.168.1.0/255.255.255.0. Esto significa que cualquier máquina desde 192.168.1.1
hasta 192.168.1.254 podrá acceder a Squid.
Caso 2
Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un fichero que contenga
dicha lista. Genere el fichero /etc/squid/lista, dentro del cual se incluirán solo aquellas direcciones IP que desea
confirmen la Lista de Control de acceso. Ejemplo:
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.15
192.168.1.16
192.168.1.20
192.168.1.40
Denominaremos a esta lista de control de acceso como redlocal:
acl redlocal src "/etc/squid/lista"
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:
# Recommended minimum configuration:

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl redlocal src "/etc/squid/lista"
A continuación procedemos a aplicar la regla de control de acceso:
http_access allow redlocal
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:
#
http_access allow localhost
http_access allow redlocal
http_access deny all
La regla http_access allow redlocal permite el acceso a Squid a la Lista de Control de Acceso denominada redlocal,
la cual está conformada por las direcciones IP especificadas en el fichero /etc/squid/lista. Ésto significa que cualquier
máquina no incluida en /etc/squid/lista no tendrá acceso a Squid.
Cache con aceleración.

Cuando un usuario hace petición hacia un objeto en Internet, este es almacenado en el cache de Squid. Si otro usuario hace
petición hacia el mismo objeto, y este no ha sufrido modificación alguna desde que lo accedió el usuario anterior, Squid
mostrará el que ya se encuentra en el cache en lugar de volver a descargarlo desde Internet. Esta función permite navegar
rápidamente cuando los objetos ya están en el cache de Squid y además optimiza enormemente la utilización del ancho de
banda.
En la sección HTTPD-ACCELERATOR OPTIONS deben habilitarse los siguientes parámetros:
httpd_accel_host virtual
httpd_accel_port 0
httpd_accel_with_proxy on
Página 30
Si se trata de un Proxy transparente deben utilizarse con las siguientes opciones, considerando que se hará uso del cache de un
servidor web (Apache) como auxiliar:
# Debe especificarse la IP de cualquier servidor Web en la red local

# o bien virtual
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
La configuración de Squid como proxy trasparente solo requiere complementarse utilizando una regla de iptables que se
encargará de redireccionar peticiones haciéndolas pasar por el puerto 8080.
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Por defecto el parámetro httpd_accel_with_proxy viene con el valor off, es importante no olvidar cambiar este valor por
on.
Estableciendo el idioma por defecto.

Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un
momento dado. Dichas traducciones se pueden encontrar en /usr/lib/squid/errors/. Para poder hacer uso de las páginas
de error traducidas al español, es necesario cambiar un enlace simbólico localizado en /etc/squid/errors para que apunte
hacia /usr/lib/squid/errors/Spanish en lugar de hacerlo hacia /usr/lib/squid/errors/English.
Elimine primero el enlace simbólico actual:
rm -f /etc/squid/errors
Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros correspondientes a los errores traducidos al
español.
Para RedHat 7.x y 8.0

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

ln -s /usr/share/squid/errors/Spanish /etc/squid/errors
Iniciando, reiniciando y añadiendo el servicio al arranque del sistema.

Una vez terminada la configuración, ejecute el siguiente comando para iniciar por primera vez Squid:
/etc/rc.d/init.d/squid start ó service squid start
Si necesita reiniciar para probar cambios hechos en la configuración, ejecute lo siguiente:
/etc/rc.d/init.d/squid restart ó service squid restart
Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, ejecute lo siguiente:
/sbin/chkconfig --level 345 squid on
Lo anterior habilitará a Squid en los niveles de corrida 3, 4 y 5.
Página 31
Cuidado
Usted NO tiene porque editar cosa alguna en /etc/rc.d/rc.local o
/etc/inittab para que Squid -así como cualquier otro servicio- inicie en el
arranque del sistema.
Ajustes para el Firewall o script de Enmascaramiento de IP.

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

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

• ftp://updates.redhat.com/9/en/os/i386/, si su distribución es Red Hat™ Linux 9
Antes de desinstalar ipchains, que se instala de modo pre-determinado en Red Hat Linux 7.x, primero debe eliminarse cualquier
regla que pudiese existir.
/sbin/ipchains -X
/sbin/ipchains -F
/sbin/ipchains -Z
A continuación debe removerse el módulo de ipchains para permitir la carga del módulo ip_tables.
/sbin/rmmod ipchains
/sbin/modprobe ip_tables
Para terminar, si utiliza Red Hat Linux 7.2 y 7.3, se debe desinstalar ipchains y toda la paquetería que dependa de éste.
rpm -e ipchains lokkit gnome-lokkit firewall-config
Esto ajustes deben poder permitir utilizar iptables en lugar de ipchains sin mayor problema.
Re-direccionamiento de peticiones.
En un momento dado se requerirá tener salida transparente hacia Internet para ciertos servicios, pero al mismo tiempo se
necesitará re-direccionar peticiones hacia servicio WWW, WWW SSL, FTP, GOPHER o WAIS hacia el el puerto donde
escucha peticiones Squid (8080), de modo que no haya salida alguna hacia alguno de estos protocolos sin que ésta pase antes
por Squid.
Página 32
El re-direccionamiento lo hacemos a través de iptables. Considerando para este ejemplo que la red local se accede a través de
una interfaz eht0, el siguiente esquema ejemplifica un re-direccionamiento:
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Lo anterior hace que cualquier petición hacia el puerto 80 (servicio HTTP) hecha desde la red local hacia el exterior, se re-
direccionará hacia el puerto 8080 del servidor.
Script ejemplo de Enmascaramiento de IP con iptables.

El guión que mostramos en la tabla a continuación considera que se dispone de dos interfaces: eth0 y eth1. Para nuestro
ejemplo la red local se accede por la interfaz eth0 y la salida hacia Internet de hace por la interfaz eth1. Utilice Firestarer para
configurar el enmascaramiento y muro contrafuegos siempre que sea posible.
Cuidado
Este script NO es sustituto para un script de firewall.
#!/bin/sh
# cargamos los módulos del kernel necesarios:
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc
modprobe ipt_REJECT
modprobe ipt_REDIRECT
modprobe ipt_TOS
modprobe ipt_MASQUERADE
modprobe ipt_LOG
modprobe iptable_mangle
modprobe iptable_nat
modprobe ip_nat_ftp
modprobe ip_nat_irc
# Habilitamos el reenvío de direcciones IP

if [ -e /proc/sys/net/ipv4/ip_forward ]; then
fi
# Estableciendo política de reenvío del enmascaramiento

iptables -t filter -P FORWARD DROP
# Reenvío de trafico intento-externo y externo-interno

iptables -t filter -A FORWARD -d 0/0 -s 192.168.1.0/255.255.255.0 -o eth0 -j ACCEPT
iptables -t filter -A FORWARD -d 192.168.1.0/255.255.255.0 -j ACCEPT
# Enmascaramiento de todo el trafico saliente

# NOTA: la salida hacia Internet es por la interfaz eth0
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
# No enmascararemos tráfico externo

iptables -t nat -A POSTROUTING -o eth1 -d 0/0 -j ACCEPT
# Permitir al tráfico de la red interna ir a donde sea

iptables -t filter -A INPUT -s 192.168.1.0/255.255.255.0 T -d 0/0 -j ACCEPT
iptables -t filter -A OUTPUT -s 192.168.1.0/255.255.255.0 -d 0/0 -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -s 192.168.1.0/255.255.255.0 -d 0/0 -j ACCEPT
# Re-direccionamiento hacia el puerto 8080 (donde Squid escucha peticiones)

# para cualquier petición originada desde la red local hacia servicios que
# utilicen protocolo http, https y ftp.
Página 33
# Pueden añadirse más re-direccionamientos a discreción del administrador.
# NOTA 1: la red local se accede con la interfaz eth1
# HTTP
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Página 34
Capítulo 3
Introducción a FTP
FTP (File Transfer Protocol; Protocolo de Transferencia de Archivos) existe en Internet desde 1971. De forma extraordinaria,
el protocolo ha permanecido con muy pocos cambios hasta hoy. Por otro lado, los clientes y los servidores son constantemente
mejorados y refinados. Aquí se estudia la instalación y configuración de un servidor particularmente refinado, el servidor de
FTP de la Universidad de Washington, más conocido como wu-ftpd.
La mayoría de las distribuciones de Linux vienen con wu-ftpd como servidor de FTP por defecto. Muchos sitios comerciales
no Linux también utilizan wu-ftpd en lugar del servidor que viene con sus variantes de UNIX por las mismas razones que
wu-ftpd es el servidor que se ha elegido para Linux: su estabilidad, flexibilidad y seguridad.
En lo que sigue analizaremos cómo bajarse la versión última de wu-ftpd y compilarla e instalarla. También mostraremos
cómo configurar su acceso privado, así como el acceso anónimo. Y por último, mostraremos cómo configurar dominios
virtuales con wu-ftpd.
El ABC de FTP
El acto de transferir un archivo de un equipo a otro puede parecer trivial, pero en realidad no lo es. Primero describiremos paso
a paso los detalles de la interacción cliente/servidor de FTP. Aunque esta información no es crucial para ser capaz de conseguir
configurar y arrancar un servidor FTP, es importante cuando necesite considerar temas de seguridad así como cuando se tengan
problemas.
La relación cliente/servidor
Cuando un cliente FTP se quiere conectar con un servidor FTP, elige un puerto alto al azar (un puerto con un número mayor
que 1024) como su origen y el puerto 21 como destino en el servidor FTP (el puerto 21 es el puerto FTP definido como
estándar). Una vez establecida la conexión, el cliente puede entrar e introducir comandos para navegar por los directorios del
servidor FTP.
Cuando el cliente hace la petición de una transferencia de un archivo, el cliente reserva otro puerto alto aleatorio y empieza a
escuchar por él. Envía su número de puerto nuevo al servidor FTP sobre la conexión existente. El servidor FTP toma ese
número de puerto e inicializa una conexión nueva desde uno de sus puertos altos aleatorios a número de puerto que le
proporciona el cliente. La conexión original se mantiene abierta para que el cliente y el servidor puedan seguir enviándose
información adicional «fuera» del mensaje (por ejemplo, interrumpir la transferencia).
Este diseño, concebido a principios de los años setenta, se asumió como algo razonable durante un largo período de tiempo en
Internet: los usuarios de Internet son un grupo de amigos que se conocen bien. Se estaba de algún modo protegido por el hecho
de que el núcleo de Internet lo fundó la NSF (Nacional Science Fundation-Fundación de ciencia nacional), y no se permitía
dentro a organizaciones comerciales a menos que trabajaran en conjunto con el instituto de investigación. Los laboratorios de
investigación académicos y gubernamentales formaban la mayoría de los usuarios.
Alrededor de 1990-1991, la NSF dejo de correr con los gastos del núcleo de Internet e Internet se hizo comercial. Al principio,
no era muy grande. Entonces llegó la World Wide Web, la Telaraña Mundial (WWW) y la población de la Red explotó (con
los problemas de seguridad).
Muchos sitios empezaron a usar firewalls para proteger sus redes internas del «Gran Malvado Internet». Sin embargo, los
firewalls consideran que las conexiones arbitrarias realizadas por los puertos altos desde Internet a los puertos altos de la red
interna son una cosa mala. Como resultado, muchos firewalls implementan proxies a nivel de aplicación para FTP, los cuales
siguen la pista a las peticiones FTP y abren los puertos altos cuando se necesita recibir datos de un sitio remoto.
Naturalmente, no todos los firewalls son tan elegantes. Muchos sitios confían en los filtrados de paquetes de los firewalls, los
cuales no entienden los datos que pasan a través de ellos, pero saben que los datos que se envían a un puerto alto son malos y
así los devuelven. Este tipo de firewall no permite trabajar a FTP porque FTP confía en ser capaz de abrir una conexión de
vuelta al cliente por un puerto alto.
Ahora volvamos atrás en el tiempo y pensemos en cuando FTP fue creado y el ancho de banda era un lujo. Cuando alguien
quería conseguir una transferencia de un archivo de una máquina A a una máquina B mientras tiene una sesión con la máquina
C, el proceso de transferencia del archivo de la máquina A a la máquina C y desde C hasta la máquina B consumía un montón
de ancho de banda. Así que los diseñadores del protocolo FTP dieron con una solución: hacer posible que alguien situado en la
Página 35
máquina C transfiriera un archivo desde la máquina A hasta la B directamente. Esto se realizó gracias a una transferencia
pasiva.
Las transferencias pasivas se consiguen iniciando la conexión para transferencia de datos desde el lado del cliente en lugar de
ser el servidor quien inicia la conexión. Desde el punto de vista de los firewalls, esto permite que los clientes continúen seguros
detrás del firewall sin la necesidad de reglas complejas que permitan la conexión de entrada.
¿Cómo conseguir la última versión de wu-ftpd?

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

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

Desde el subdirectorio en el que haya desempaquetado wu-ftpd, necesita escribir
# ./build 1nx
y ya está hecho. El script lleva a cabo el proceso de compilación y verificación por usted. Al final del proceso de compilación,
debería ver algo parecido a esto:
Executables are in bin directory:

text data bss dec hex filename
125940 15156 72608 213704 342c8 bin/ftpd
5311 448 36 5795 16a3 bin/ftpcount
4959 364 36 5359 14ef bin/ftpshut
5311 448 36 5795 16a3 bin/ftpwho
2154 244 28 3026 bd2 bin/ckcontig
Done
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:
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
El archivo /etc/inetd.conf se gestiona con el programa inetd, el cual actúa como una especie de «super-servidor», que
escucha las peticiones de red en lugar de otros servidores de aplicación e inicia las aplicaciones servidores cuando detecta una
petición de conexión para ellas. Si el archivo de configuración /etc/inetd.conf cambia, necesita enviarle al proceso inetd
una señal indicándole que debe recargar su archivo de configuración. Esto se hace de una de estas dos formas:
1. Ejecutando el comando siguiente:
kill -l `ps auxw | grep inetd | grep -v grep | awk '{ print $2}' `
2. Mire si su distribución guarda el ID del proceso en el archivo /var/run/inetd.pid. Si es así, puede usar:
kill -1 'cat /var/run/inetd.pid'
Y debería ser capaz de realizar ftp sobre su propio sistema. No se preocupe si no puede entrar en él todavía (explicaremos
algunos detalles más después), pero al menos debería ser capaz de conseguir el símbolo del sistema FTP.
Configuración de wu-ftpd
El paquete wu-ftpd viene con varios archivos de configuración de ejemplo que son fáciles de modificar e instalar en su
servidor FTP. Más tarde, presentaremos algunas configuraciones predefinidas por si tiene necesidad de un inicio rápido. Esta
sección se enfoca en los detalles que ofrece wu-ftpd. Encontrará una herramienta de referencia práctica en lugar de un tutorial,
pero al menos echarle un vistazo está justificado.
Control de acceso a través del archivo /etc/ftpaccess

El archivo /etc/ftpaccess contiene cinco tipos de comandos:
• Control de acceso.
• Información automática para clientes.
• Configuración de entrada.
• Permisos.
• Controles de tipo de archivo y directorio.
Examinaremos cada comando específico integrado en cada uno de los grupos.
Página 37
Control de acceso
Controlar quién entra y quién no en el servidor FTP es un aspecto crucial de la gestión de un servidor. Los comandos siguientes
le permiten hacer eso.
CLASS El comando class define una clase nueva de usuarios en su sistema. No garantiza ni concede
ningún derecho en especial, pero la definición de una clase es necesaria para referenciar un
grupo de usuarios en los comandos que se estudian más tarde.
El formato del comando class es
class nombre-clase tipo dirección...
Donde nombre-clase es el nombre de la clase nueva que defina. Tipo es uno de estos tres
valores: anonymous, real o guest.
• Los usuarios anonymous (anónimos) son justamente eso: usuarios que acceden al
servidor sin tener ningún tipo de permiso explícito. Note que por definir una clase
que permita usuarios anónimos, no está configurando un FTP anónimo.
• Los usuarios real (reales) deben tener una cuenta y una shell válida en el sistema. En
el caso de FTP, definimos una shell válida como cualquier shell que aparezca en el
archivo /etc/shells.
• Los usuarios guest (invitados) son aquellos que no tienen una cuenta real en el
servidor, pero están incluidos explícitamente en el grupo de invitados (se explica
más tarde).
Por último, dirección... es la lista de direcciones IP que se originan desde la clase

definida. El asterisco (*) es un metacarácter que indica que todas las direcciones IP son
válidas para la clase definida.
class mi-clase anonymous 10.10.*
define la clase mi-clase, la cual consta únicamente de usuarios anónimos cuyas direcciones IP
comienzan por 10.10.
Podemos tener tantas entradas de clase como queramos.
AUTOGROUP El comando autogroup se usa para indicar a qué grupos de usuarios anónimos de UNIX se
pretende cuando se entra en el servidor FTP. Mediante la configuración del grupo al que
pertenece, puede retener un control ajustado sobre qué archivos puede o no puede tener
acceso. El formato del comando autogroup es
autogroup nombre-grupo clases...
donde nombre-grupo es el nombre del grupo al que quiere que pertenezcan los usuarios
anónimos (observe que el nombre-grupo se debería corresponder con una entrada del
archivo /etc/group) y clases... es una lista de clases a las que quiera afectar con este
comando.
Por ejemplo, si define tres clases,
class a anonymous,real 10.10.*

class b anonymous,real,guest 192.168.5.*
class c anonyrnous,real 192.168.7.10 192.168.7.11 192.168.7.12
puede especificar una clase autogroup como ésta:
autogroup anonftp a b
Ahora alguien de las clases a o b que entre como anónimo tiene que trabajar dentro de los
Página 38
límites del grupo anonftp.
DENY El comando deny le permite bloquear el acceso a su sistema basándose en la dirección IP de

origen o en el nombre de máquina. El formato del comando deny es de esta forma:
deny direcciones archivo_mensaje
donde dirección es la dirección IP y el archivo_mensaje es el nombre de archivo del

mensaje que quiera devolver cuando traten de conectarle. Por ejemplo, el comando
deny 192.168.66.7 /home/ftp/no_evil_crackers
debería provocar que los contenidos del archivo /home/ftp/no_evil_crackers se

enviarán a cualquier usuario que trate de entrar en el servidor desde la dirección IP
192.168.66.7.
Nota
Debido a que la resolución de nombres inversa es poco fiable, se recomienda que
use sólo direcciones IP.
GUESTGROUP El comando guestgroup es útil cuando tiene usuarios reales, pero que desea que sus
privilegios se vean recortados de forma similar a los usuarios anónimos. El formato del
comando es:
guestgroup nombre-grupo...
donde nombre-grupo es el nombre de uno o más grupos (tomado del /etc/group) que
quiera restringir. Para restringir usuarios de esta forma, además de la entrada en el archivo
/etc/ft-paccess, necesita cambiar el formato de cada entrada de usuario del
/etc/passwd. El formato nuevo debería tener su directorio /home situado entre los
caracteres (/./). Antes de la barra debería estar el directorio raíz efectivo y después de la
barra debería estar el directorio home del usuario efectivo. Por ejemplo, la entrada
cor:ilhsvmt1m8wh:256:1024:Carlos Rodriguez:/ftp/./cor:/bin/ftponly
significa que /ftp es el nuevo directorio raíz relativo del usuario. Esto debería prevenir que
el usuario vel el directorio /home real, o cualquier otro directorio de path. Debido a esto,
necesita situar un directorio bin, etc y lib en /ftp donde existan las bibliotecas y binarios
que permitan funcionar a ftp. Este aspecto es idéntico a la configuración de un usuario
anónimo, el cual se explica más tarde.
Relativo a /ftp habrá un subdirectorio llamado cor, el cual será el directorio home de
entrada vía FTP. Debido a que /bin/ftponly no es una shell real, no podría realizar un
telnet al sistema. Sin embargo, asegúrese de que /bin/ftponly se lista en el archivo
/etc/shells.
LIMIT El comando limit le permite controlar el número máximo de usuarios que pueden entrar en
el sistema mediante FTP por clase y día de la semana. El formato del comando limit es
limit clase n fecha archivo-mensaje
donde clase es el nombre de la clase afectada, n es el número máximo, fecha es el día y la

hora que se pennite entrar a los usuarios y archivo-mensaje es el archivo que se muestra a
los usuarios que no puedan entrar.
El formato de la entrada fecha es un poco difícil. El parámetro es de la forma de una cadena
Página 39
de texto delimitada por comas, donde cada opción es para un día separado. De domingo a
sábado toman la forma de Su, Mo, Tu, We, Th, Fr y Sa, respectivamente, y se pueden indicar
todos los días de la semana con Wk. La hora va en formato militar, sin un símbolo de dos
puntos separando horas y minutos. Un rango se especifica con el carácter guión (-).
Por ejemplo, para limitar a la clase anonpeoples a un máximo de 25 de lunes a jueves

durante todo el día y los viernes hasta las 7 de la tarde, debería usar la línea
limit anonpeoples 25 MoTuWeTh,FrOOOO-1900 /home/ftp/.message.too_many
donde los contenidos del archivo /home/ftp/.message.too_many se devuelven al usuario

si se excede el máximo.
Nota
El soporte del comando limit es para aquellos servidores que tengan limitaciones
en términos de ancho de banda disponible, o para servidores que necesiten estar
disponibles para otras tareas durante ciertos momentos. Por ejemplo, un servidor
FTP que hace disponibles hojas de errores de productos debería ser accesible por
los clientes durante las horas normales de oficina. Sólo durante las horas de la
noche, cuando el tráfico de negocios cae hasta niveles aceptables, puede
considerarse usar la máquina como colección de bandas discográficas. El comando
limit le permite llevar a cabo este tipo de configuración.
LOGINFAILS Este comando le permite limitar el número de entradas fallidas consecutivas de un usuario
que se conecte. El formato del comando es
loginfails n
donde n es el número de entradas fallidas que quiera tolerar. Por ejemplo, si quiere que el
sistema corte automáticamente la conexión de alguien que falla en introducir su contraseña
después de tres veces, debería usar
loginfails 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
donde nombre-grupo-acceso es el nombre que usa el cliente para referenciar el grupo

especial, contraseña-encriptada es la contraseña que necesitan los usuarios para
proporcionar (con SITE GPASS) para acceder al grupo y grupo-real es el grupo actual
referenciado en el archivo /etc/group.
Para generar la entrada de la contraseña encriptada de este archivo, necesita usar la función
Página 40
crypt. Se puede acceder a él a través de este script de Perl:
#!/usr/bin/perl
print "Introduzca la contraseña a encriptar: ";
chop ($password=<STDIN>);
print "LA contraseña encriptada es: ", crypt ($password, $password);
Simplemente escriba este script y guárdelo como un archivo. Cambie los permisos para
hacerlo ejecutable (por ejemplo, chmod 755 mi-script-perl) y ejecútelo. Escribiremos
la contraseña que quiera introducir y mostraremos la cadena encriptada resultante.
Control de mensajes
Cuando un usuario entra en su sistema mediante FTP, encontrará útil presentar algún tipo de mensaje a estos usuarios entrantes.
En otras situaciones, encontrará práctico presentar un mensaje especial si introducen un directorio particular o realiza una cierta
opción. Esta sección estudia cómo usar los comandos en el archivo /etc/ftpaccess de wu-ftpd para hacerlo.
BANNER Este comando le permite presentar un mensaje a un usuario que se conecte al servicio FTP,
pero que no ha entrado aún. El formato de este comando es
banner nombre-archivo
donde nombre-archivo es el nombre de un archivo (con el path completo) que quiera

mostrar. El archivo debe estar en formato texto ASCII. Por ejemplo:
banner /home/ftp/welcome_to_my_ftp_site
Nota
Los administradores que gestionan servidores FTP muy utilizados comentan que
un buen mensaje es crucial en la limitación del número de usuarios.
EMAIL El comando email le permite especificar la dirección de correo electrónico del administrador
del sitio. Los comandos como message (que se explica más tarde) usan la información
también. El formato de este comando es
Email dirección
donde dirección es la dirección de correo del administrador del sistema. Debería considerar
usar una dirección de correo genérica del tipo 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:
message archivo cuando clase...
donde archivo es el archivo que se mostrará al usuario, cuando es la condición que deba
cumplirse para mostrarse el mensaje y clase (que es opcional) es la lista de clases sobre la
que se aplicará.
El parámetro cuando puede tomar una de estas dos formas, LOGIN o CWD=path, y esta
Página 41
característica es la que hace este comando diferente del comando banner.
• Si es LOGIN, el mensaje se visualizará después de una entrada al sistema correcta.
• Si es CWD=path, el mensaje se mostrará cuando un usuario vaya al directorio path.
El archivo del mensaje es un archivo de texto ordinario con algunas palabras claves. Estas
palabras claves son las siguientes:
Opción 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.
Un ejemplo del comando message en acción es
Message ./.demasiados.usuarios LOGIN anonusers
donde .demasiados.usuarios es un archivo parecido a éste:
Lo siento %R, pero se han alcanzado %N de los %M usuarios

de %L. Estamos trabajando para conseguir un servidor más
grande pero mientras tanto le pedimos paciencia. Por
favor, pruebe más tarde.
Su Administrador FTP, %E
Nota
Los mensajes desencadenados por la entrada de usuarios anónimos deben ser
relativos al directorio FTP anónimo.
README El comando readme permite que el servidor informe automáticamente a un usuario cuando
se actualiza un archivo en particular. El comando toma la forma
Readme archivo cuando clase
donde archivo es el nombre de path completo del archivo que quiere que muestre el
servidor FTP, cuando es cuándo quiere que se le diga al usuario (el formato de cuando igual
al del comando message) y clase es la clase sobre la que se aplicará. Los parámetros
cuando y clase son opcionales. Por ejemplo:
readme ./README CWD=/pub/patches
Nota
Los mensajes desencadenados por la entrada de usuarios anónimos deben ser
relativos al directorio FTP anónimo.
Página 42
LOG
Puede usar wu-ftpd para configurar sobre qué información se va a realizar log. Esta información es una manera estupenda de
conseguir una buena forma de exponer y organizar sus servicios.
Esta sección explica los comandos usados en la personalización de las entradas del log.
LOG COMMANDS Si quiere hacer log de cada comando introducido por los usuarios conectados a su
servicio FTP, querrá usar los comandos de log. Su uso es el siguiente:
log commands lista-tipo
donde lista-tipo es una lista separada por comas del tipo de usuario sobre cuyos
comandos quiere hacer log, como el descrito con el comando class. Los tipos de listas
válidos son:
anonymous, guest y real. Por ejemplo, si quiere realizar log sobre todos los
comandos escritos por usuarios anónimos, debería introducir
log commands anonyrnous
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:
log transfer lista-tipo direcciones
donde lista-tipo es el tipo de usuario sobre cuyos comandos quiere hacer log como
el descrito con el comando class (es decir, anonymous, guest y real) y direcciones
es una lista separada por comas de la dirección (entrante ó saliente) de la transferencia
sobre la que se desea hacer log (es decir, inbound y outbound). Por ejemplo, para
hacer log de las conexiones entrantes y salientes de los usuarios guest, escriba
log transfer guest inbound,outbound
Otros comandos de servidor

Por supuesto, siempre hay comandos que no caen en ninguna de las categorías. Consideramos los siguientes:
ALIAS Con frecuencia es conveniente crear atajos para los directorios de acceso más frecuente.
Mediante el uso del comando alias, puede hacer esto. El formato del comando es:
alias nombre-alias directorio
donde nombre-alias es el propio alias y directorio es el directorio completo sobre el

que quiere crear un atajo. Por ejemplo,
alias redhat /pub/linux/distributions/redhat
debería permitir que un usuario que introduzca el comando cd redhat y vaya directamente
al directorio /pub/linux/distributions/redhat.
CDPATH Equivalente a la variable de entorno PATH, cdpath le permite establecer un path de

directorios para los usuarios que se conecten a su servicio FTP. El formato del comando es:
cdpath directorio
Página 43
donde directorio es el nombre del directorio que quiera añadir al path. Por ejemplo, si usa
cdpath /pub/linux
cdpath /pub/recipes
y un usuario introduce el comando cd microwave, wu-ftpd debería buscar en los

directorios siguientes:
• ./microwave
• Alias llamados microwave
• /pub/linux/microwave
• /pub/recipes/microwave
Nota
La diferencia clave entre alias y cdpath es que alias especifica un mapeado
simple desde un nombre de directorio a otro. Por otra parte, cdpath especifica una
lista de directorios que se deben comprobar cuando un usuario utiliza el comando
cd.
COMPRESS El servidor wu-ftpd ofrece la posibilidad de realizar conversiones de archivos sin uso de
archivos intermedios. Una conversión específica puede comprimir o descomprimir un archivo
antes de enviarlo a un usuario. Esto es especialmente útil para los clientes que no tengan la
misma utilidad de compresión que la suya o para clientes con enlaces lentos que quieran
comprimir un archivo antes de enviarlo a la red. El formato del comando es
compress switch clase
donde switch es ON u OFF y clase es real, guest o anonymous. Lo malo de usar esta
característica es que también debe tener configurado el archivo /etc/ftpconversions. Lo
estudiaremos más tarde en este mismo capítulo.
TAR Como el comando compress, el comando tar permite a los clientes unir o desunir un
archivo antes de bajárselo. El formato del comando es:
tar switch clase
donde switch es ON u OFF y clase es real, guest o anonymous.
Nota
Éste es un mecanismo estupendo para usuarios que se bajan subdirectorios de
forma recursiva.
Permisos
La configuración de los permisos de archivos en un servidor FTP es muy importante. Necesita asegurarse de configurar los
permisos correctos de los archivos para no compartir lo que no deba ser compartido y no alterar los archivos que no deban ser
modificados. Los comandos que se analizan en esta sección le ayudan a mantener la integridad del sistema.
CHMOD Este comando le permite decidir si quiere dar a los usuarios el derecho a cambiar permisos de
los archivos de sus sitios. (Deben ser propietarios de un archivo para ser capaces de cambiar
sus permisos.) El formato del comando es
chmod switch clase
Página 44
donde switch es ON u OFF y clase es real, guest o anonymous. En general, querrá dar
este tipo de permiso únicamente a usuarios reales. Por ejemplo:
chmod 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 switch clase
donde switch es ON u OFF y clase es real, guest o anonymous. Por ejemplo:
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 switch clase
donde switch es ON U OFF y clase es real, guest o anonymous. Por ejemplo:
overwrite ON real
RENAME El comando rename le permite decidir si quiere que los usuarios sean capaces de renombrar
archivos de su propiedad en el servidor FTP. El formato del comando es:
rename switch clase
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 switch clase
umask ON real
PASSWD-CHECK Los sitios proporcionan acceso anónimo a las peticiones de usuarios que introducen su
dirección de correo como contraseña; wu-ftpd le permite decidir lo estricto que quiera ser
para forzar la comprobación de contraseña si se ejecuta como un sitio anónimo. El formato
del comando es
passwd-check strictness enforcement :
donde strictness es none, trivial o rfc822 y enforcement es warn o enforce.
Si strictness es none, el usuario sólo tiene que introducir algo en el campo contraseña y
Página 45
se le aceptará por wu-ftpd. Trivial sólo requiere que la dirección de correo tenga un
símbolo @ en él. La especificación de rfc822 requiere que la dirección de correo sea
completamente compatible con el Message Heder Standard (Estándar de cabecera de
mensaje). Por ejemplo, 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:
path-filter lista-tipo mensaje expres-reg-perm expres-reg-deneg
donde lista-tipo es la lista de usuarios separada por comas a los que afecta este comando.
Los tipos de usuarios aceptados son anonymous, guest y real. Mensaje es el archivo que
se muestra al usuario si su nombre de archivo no pasa el filtro. Expres-reg-perm es la
expresión regular que debe cumplir el nombre de archivo si el usuario lo quiere descargar.
Expres-reg-deneg es la expresión regular que no debe cumplir el nombre de archivo si el
usuario lo quiere descargar. Por ejemplo, la línea
path-filter anonyrnous /home/ftp/.badfilename UL* gif$
nos dice que los usuarios anónimos deben empezar los nombres de sus archivos a descargar
con las letras «UL» y no terminarlos con «gif». Si el nombre del archivo no cumple este
criterio se enviará al usuario el contenido de /home/ftp/.badfile-name.
UPLOAD Puede usar el comando upload, junto con path-filter, para controlar los archivos
situados en su servidor. El comando upload especifica los pennisos que tiene el cliente para
colocar archivos en ciertos directorios, así como los permisos de los archivos que se pueden
modificar. El formato del comando es
upload directorio dir-glob switch propietario grupo perms mkdir
donde directorio es el directorio que se ve afectado por este comando, dir-glob es la

expresión regular usada para determinar si un subdirectorio bajo directorio es un sitio válido
para hacer una descarga y switch es YES o NO, estableciendo si la descarga puede realizarse
en directorio. Los parámetros propietario, grupo y perms se establecen aquí (el
propietario y grupo del archivo y sus permisos). Por último, puede especificar la operación
mkdir como DIRS o NODIRS, determinando si el cliente puede crear subdirectorios bajo el
directorio especificado. Por ejemplo:
upload /home/ftp /incoming yes ftp ftp 0400 nodirs
Nota
El comando upload afecta sólo al directorio elegido, no a los subdirectorios que
están por debajo de él. Esto previene que los usuarios remotos puedan crear
directorios en su servidor y esconder archivos en él.
El archivo log
Como estudiamos antes, el archivo de log es importante en las operaciones del día a día. Con él, puede realizar un análisis de su
sitio FTP y determinar cosas como los archivos más accedidos y los patrones de uso del sitio en general.
Página 46
La posición por defecto del archivo de log por defecto es /var/log/xferelog. Cada línea del log consta de una entrada,
como la mostrada en la Tabla 13.1.
Cabecera de entrada de Log Descripción

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

archivo, lo añade. Esto se debería usar en el caso donde un archivo que, no se haya
comprimido tenga .gz añadido como si lo estuviera y se envía al cliente.
Addonpre El prefijo add-on es lo contrario a strippre. Permite añadir un prefijo al nombre

del archivo antes de enviarlo a un cliente.
External Esta entrada especifica qué programa (externo a wu-ftpd) se ejecuta cuando
coincida un filtro. En el caso de las descargas, el archivo resultante de la conversión
debería enviarse a la salida estándar de programas (stdout). Las descargas en el
servidor se enviarán a la entrada estándar (stdin). Puede especificar el nombre de
archivo que pidió el cliente en la línea de comandos mediante un comando externo
mediante el uso de %s en lugar del propio nombre. El servidor buscará y reemplazará
automáticamente cada ocurrencia de %s por el nombre del archivo del cliente.
Type En el mundo de wu-ftpd, los archivos son de uno de estos tres tipos: regulares,
ASCII o directorios (T_REG, T_ASCII y T_DIR, respectivamente). Este campo le
permite especificar el tipo de archivo sobre el que wu-ftpd actuará si coincide el
filtro del nombre de archivo. Puede especificar varias opciones separándolas con el
símbolo pipe (|). Por ejemplo, T_REG|T_ASCII especifica que quiere que el filtro se
aplique sobre cualquier tipo de archivo.
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
Una entrada ejemplo

La siguiente es una entrada de ejemplo que comprime archivos bajo demanda usando gzip. Esto debería permitir a alguien que
quiera conseguir el archivo orb_discography.tar, que el servidor lo comprima usando gzip antes de enviarlo. La
configuración de la línea es la siguiente:
:::.gz:/bin/gzip -9 -c %s:T_REG|T-ASCII:O_COMPRESS:GZIP
Los dos primeros parámetros (prefijo strip y sufijo strip) no son necesarios puesto que no tienen ningún valor. El tercer
parámetro (prefijo addon) tampoco se aplica porque no tiene tampoco nada que añadir al comienzo del archivo. El cuarto
parámetro, .gz (sufijo addon), especifica que el nombre del archivo debería tener añadido .gz después de ejecutar este filtro.
El quinto parámetro (comando externo) especifica la invocación exacta del programa gzip a fin de realizar la compresión del
archivo. Observe que usamos %s en lugar de un nombre de archivo. El sexto parámetro (tipo de archivo) le dice a wu-ftpd que
puede realizar compresión sobre los archivos regulares y ASCII. El séptimo parámetro, O_COMPRESS (el campo opciones), le
dice al servidor que la acción a realizar sobre el archivo es la compresión. Por último, el último campo es un recuerdo legible de
que hace este filtro: ejecuta gzip.
Aunque su apariencia intimida, no se preocupe! Es poco probable que necesite cambiar la configuración por defecto del archivo
que viene con wu-fipd, puesto que cubre las conversiones más comunes.
Página 48
Configuración del acceso a la máquina
El archivo /etc/ftphosts le permite explícitamente denegar o permitir usuarios basándose en su dirección IP original. Cada línea
del archivo tiene la forma:
allow nombre-usuario dirección
deny nombre-usuario dirección
donde nombre-usuario es el nombre de usuario que utiliza cuando se conecta al servicio FTP y dirección es la dirección IP
original. Puede añadir varias direcciones en la lista separadas por comas.
Configuraciones típicas
Con todas las opciones disponibles, la configuración del servidor wu-ftpd puede amilanarle un poco, cuando no debería.
Parecida a las configuraciones de DNS, las configuraciones más comunes son también muy fáciles de realizar. En esta sección
recorreremos todas estas combinaciones para ayudarle a realizarlas.
Acceso sólo anónimo

Bajo el modelo UNIX, cada proceso debe tener un propietario. En el caso de un usuario FTP anónimo, este propietario debería
tener unos derechos de acceso a archivos mínimos y únicamente ser capaz de ver los archivos del área FTP pública. Para llevar
a cabo esto, necesita asegurarse de que está configurado el usuario «ftp» (esto se hace automáticamente en el Linux de Red
Hat).
Configuración del usuario anónimo
Truco
Si usa el Linux de Red Hat, puede instalar el RPM anonftp-2.8-1.i386.rpm
en lugar de recorrer todos los pasos que se explican en esta sección.
Puede comprobar fácilmente si tiene un usuario anónimo examinando su archivo /etc/passwd. Si existe el usuario ftp,
puede saltarse este paso. Si no lo tiene, querrá crear un nuevo usuario llamado ftp usando comandos parecidos a:
# echo "/bin/ftponly" >>/etc/shells
# useradd -c "FTP User" -d /home/ftp -r –s /bin/ftponly ftp
El primer comando le dice al sistema que /bin/ftponly es una shell de usuario aceptable. Esto es necesario para que el
comando useradd sea capaz de usarla, incluso si la shell no existe. La razón por la que querría configurar una shell que no
existe, pero que esté presente en /etc/shells es que pueda entrar en el sistema mediante FTP, pero no mediante un telnet.
El segundo comando crea una cuenta para el usuario ftp. Puede cambiar el directorio /home/ftp para colocarlo donde
prefiera que ocurran los accesos FTP anónimos (una partición dedicada por si piensa hacer un gran sitio). También llama a la
opción -r para que cree una cuenta del sistema, pues el directorio home no se crea automáticamente.
Por motivos de estructuración, también debería crear un grupo ftp si no existe ya. Esto se hace con el comando:
# groupadd -r ftp
El parámetro -r sirve para lo mismo que explicamos en el comando useradd.

Con la cuenta creada, necesitará asegurarse de que está configurado el directorio home para el usuario ftp anónimo. Éste es el
directorio que los usuarios verán cuando se conecten al servicio.
Página 49
Configuración del directorio FTP anónimo
Truco
Si usa el RPM anonftp-2.8-1.i386.rpm, puede saltarse estos pasos también,
puesto que la estructura de directorios se configura por usted.
El directorio FTP ánónimo debería tener los subdirectorios siguientes:

pub
bin
etc
lib
Los permisos de estos directorios deberían configurarse con los comandos siguientes:
# chown root.root bin etc lib

# chown root.ftp pub
# chmod 111 bin etc
# chmod 755 lib
# chmod 2755 pub
Cuando el usuario ftp anónimo entra, el servidor realiza un chroot, una función de sistema que cambia la definición de cuál es
el directorio raíz donde se localizan los archivos de FTP anónimos. En el caso en que los archivos FTP anónimos se localizan
en /home/ftp, el comando chroot podría cambiar la definición del directorio raíz a /home/ftp, de forma que un cd / se
referiría a /home/ftp. Esto hace que los usuarios anónimos no puedan ver otros archivos del sistema, especialmente los
sensibles como /etc/passwd. El efecto de usar chroot es que los programas que se ejecutan deben estar disponibles en el
nuevo directorio raíz, o no se podrán usar. Así, debe copiar los archivos que se muestran en la tabla siguiente en los directorios
siguientes. (Nota: Asumimos que /home/ftp es el directorio donde se sitúan los archivos de ftp anónimos.)
Archivo fuente Destino Permisos

/lib/ld-2.1.1.so /home/ftp/lib 755
/lib/libc-2.1.1.so /home/ftp/lib 755
/lib/libns1-2.1.1.so /home/ftp/lib 755
/lib/libnss_files- 2.1.1.so /home/ftp/lib 755
/usr/bin/compress /home/ftp/bin 111
/bin/cpio /home/ftp/bin 111
/bin/gzip /home/ftp/bin 111
/bin/ls /home/ftp/bin 111
/bin/sh /home/ftp/bin 111
/bin/tar /home/ftp/bin 111
Recuerde configurar correctamente los permisos de los archivos de arriba usando el comando chmod. También necesitará crear
algunos enlaces simbólicos. Las series de comandos siguientes los crearan:
# cd /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:
class anonclass anonyrnous *

class nonanon real.guest *
email ftp@domain.com
loginfails 3
limit nonanon 0 Wk0000-2359 /home/ftp/.norealusers
readme README* login
readme README* cwd=*
message /welcome .msg login
message .message cwd=*
compress yes anonclass
tar yes anonclass
chmbd no anonymous
delete no anonymous
overwrite no anonymous
rename no anonymous
log transfers anonymous inbound,outbound
passwd-check rfc822 warn
Las líneas claves son las definiciones de clase donde separamos los usuarios no anónimos de los usuarios anónimos, y la línea
limit, la cual limita los usuarios no anónimos a 0 para todos los días de la semana durante todo el día (los usuarios reales que
traten de entrar son enviados al archivo /home/ftp/.norealusers). El resto del archivo es bastante genérico. Lo verá en
muchas otras configuraciones diferentes.
Configuración del directorio /incoming
Si necesita permitir que los usuarios anónimos depositen archivos en su sistema, necesitará configurar un directorio especial de
entrada para ello. Los archivos situados allí se pueden recuperar sólo por el usuario root, no por ningún usuario anónimo. Esto
es así para impedir a los individuos con intenciones deshonestas la entrada en el servidor FTP y aprovechar un sitio de acceso
público para esconder pornografía, software pirateado o contenidos ilegales (como números de tarjetas de crédito robadas). Esto
significa su supremacía sobre su labor como administrador de sistemas, pero un campo de protección es la única forma de
asegurarse de que los archivos descargados en el servidor son aceptables para que otras personas se los bajen. Para crear este
subdirectorio, vaya al directorio de FTP anónimo (por ejemplo, /home/ftp) y cree un subdirectorio llamado incoming así:
# mkdir incoming
Entonces cambie los permisos para que sólo el usuario ftp pueda escribir allí, pero el usuario anónimo no pueda leer de él:
# chmod 300 incoming

# chown ftp.ftp incoming
y por último, añada las dos líneas siguientes a su archivo /etc/ftpaccess para controlar dónde descargan los archivos:
Página 51
upload /home/ftp * no
El primer comando upload deniega la descarga sobre todos los directorios de su servidor FTP. El segundo comando abre
explícitamente un directorio donde los usuarios anónimos pueden descargar archivos.
Usuarios sólo registrados y acceso mixto

Es aceptable ejecutar un servidor que soporte acceso mixto, es decir, proporciona usuarios anónimos y usuarios de acceso
regular a su servidor. Es también posible configurar un servidor con únicamente acceso para usuarios registrados.
Acceso mixto
Empezamos configurando el servidor como para un acceso sólo para anónimos. Una vez hecho, cambiamos el archivo
/etc/ftpaccess para que refleje
class all real,guest,anonymous *

email ftp@domain.com
loginfails 5
readme README* login
readme README* cwd=*
message /welcome.msg login
compress yes all
tar yes all
chmod no guest,anonymous
delete no guest,anonymous
overwrite no guest,anonymous
renarne no guest,anonymous
log transfers anonymous,real inbound,outbound
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
(Lea la sección de configuración de soporte de descarga en los servidores FTP anónimos para informarse de cómo configurar el
directorio incoming.)
Usuarios sólo registrados

Hay dos mecanismos para denegar el acceso a los usuarios FTP anónimos. El primero es no tener el usuario ftp en el archivo
/etc/passwd. Este método es muy simple y hace el trabajo.
Sin embargo, si quiere dejar la configuración del FTP anónimo intacta, puede denegar el acceso FTP anónimo de la misma
forma que deniega el acceso a los usuarios reales en un servidor FTP anónimo (usando el comando limit en el archivo
/etc/ftpaccess).
El archivo /etc/ftpaccess para este tipo de configuración debería ser:
class all real,guest *

class anon anonymous
ernail ftp@dornain.com
loginfails 5
limit anon 0 Wk0000-2359 /home/ftp/ .noanonusers
readrne README* login
readrne README* cwd=*
message /welcome.msg login
compress yes all
tar yes all
Página 52
chmod no guest
delete no guest
overwrite no guest
renane no guest
log transfers real inbound,outbound
donde /home/fip/.noanonusers es el archivo de texto que se envía al cliente que trata de conectarse como anónimo para
informarle de que no está permitido el acceso anónimo.
Configuración de un Servidor FTP Virtual

Con wu-ftpd puede configurar varios servidores FTP sobre una sola máquina siempre que cada servidor tenga su propia
dirección IP (ésta es una limitación de FTP, no de configurado un alias de IP y la tabla arp es conecta. Este recorrido rápido del
proceso asume que tiene una tarjeta Ethemet y quiere añadir una dirección IP virtual:
1. Asegúrese de que las direcciones IP nuevas existen en la tabla de máquinas locales (/etc/hosts) así como en la tabla
DNS. (En este ejemplo, llamaremos a la máquina earth.)
2. Ejecute el comando ifconfig para configurar el dispositivo eth0:0 con la dirección, máscara y broadcast
apropiados. Por ejemplo, para configurar el dispositivo eth0:0 con la dirección 192.168.1.42, usaría:
ifconfig eth0:0 192.168.1.42 netmask 255.255.255.0 broadcast 192.168.1.255
3. Actualice la tabla arp. Necesitará la dirección hardware de su tarjeta Ethernet para esto. Ejecute el comando
ifconfig -a para obtener esta información. Asumiendo que la dirección hardware de su tarjeta Ethemet es
00:10:4B:CB: 15:9F, escriba:
arp -s earth OO:10:4B:CB:15:9F pub
Con su dirección IP virtual establecida, ahora necesitará crear una estructura de directorios similar a la de un sitio anónimo.
Debería situarse en el directorio donde quiera hacer su sitio FTP virtual. Entonces añada el comando virtual al final de su
archivo /etc/ftpaccess. El formato del comando es:
Virtual IP tipo-fich directorio
donde IP es la dirección IP de su servidor FTP virtual y tipo-fich es el tipo del archivo al que se refiere directorio. El
valor de tipo-fich puede ser root, banner o logfile. Si tipo-fich es root, directorio debería ser el directorio donde se
configuran los archivos de FTP anónimo para el sitio virtual. Si tipo-fich es banner o logfile, la entrada directorio será el
archivo correspondiente.
Por ejemplo, para configurar el servidor FTP virtual con la dirección IP 192.168.1.42, podría realizar mi configuración de este
modo:
virtual 192.168.1.42 root /home/earth

virtual 192.168.1.42 banner /home/earth/.we1come.banner
virtual 192.168.1.42 logfile /var/log/xferlog.earth
Nota
Todos los archivos necesarios para el acceso FTP anónimo deben configurarse en
el directorio raíz del servidor FTP virtual. En nuestro ejemplo, esto significa que
los subdirectorios bin, etc, lib y pub están en el directorio /home/earth.
Conclusiones
El demonio FTP de la Universidad de Washington (www.wu-ftpd.org) es un potente servidor de FTP que ofrece todas las
características que debería necesitar para ejecutarse un servidor FTP comercial de un modo seguro. En este capítulo, analizamos
el proceso de compilación, instalación y configuración de un servidor wu-ftpd.
Específicamente, estudiamos:
Página 53
• Todas las opciones de configuración de wu-ftpd.
• Establecimiento de servidores FTP virtuales.
• Configuración de servidores FTP anónimos.
• Configuración de servidores anónimos en conjunción con servidores FTP sólo para usuarios normales.
• Detalles acerca del protocolo FTP y sus efectos en los firewalls.
Esta información es suficiente para dejar a su servidor FTP humeando durante un buen rato. Naturalmente, como todo medio
escrito sobre software, este texto tiene edad, y la información se volverá, de forma lenta pero segura, obsoleta. Asegúrese de
visitar la página Web de wu-ftpd de vez en cuando para enterarse no sólo de los últimos desarrollos, sino también de la
documentación más nueva.
Página 54
Capítulo 4
Introducción al Cliente FTP
FTP (File Transfer Protocol) es un programa que se utiliza para transferir información, almacenada en ficheros, de una
máquina remota a otra local, o viceversa.
Para poder realizar esta operación es necesario conocer la dirección IP (o el "nombre") de la máquina a la que nos queremos
conectar para realizar algún tipo de transferencia.
Es fundamental distinguir entre máquina local y máquina remota:
• Maquina Local: Es aquella desde donde nos conectamos para hacer la taransferencia, es decir, donde ejecutamos ftp.
• Maquina Remota: Es aquella a la que nos conectamos para transferir información.
Ejecución del Cliente FTP

Los pasos que hay que seguir para hacer FTP de una máquina (local) a otra (remota), son los siguientes:
1. Entrar en la máquina local (es decir, en la que vamos a trabajar físicamente)
2. Una vez dentro, nos conectaremos a la máquina remota, para lo cual haremos ftp, de una de las dos formas siguientes:
$ ftp nombre o dirección IP de la máquina remota
o bién
$ ftp
FTP> open nombre o dirección IP de la máquina remota
Una vez hecho esto nos preguntará el nombre de usuario y la contraseña, es decir:
Username nombre de usuario
password palabra clave
donde el nombre de usuario puede ser:

1. El username (login) de una cuenta en la máquina a la que voy a acceder; o bien
2. anonymous: para poder acceder al servidor de ficheros de la máquina remota.
En este caso es aconsejable (y a veces obligatorio) introducir como palabra clave, la dirección de correo electrónico.
Una vez hecho esto, ya se ha establecido comunicación con la máquina remota a través de FTP; por lo que el prompt del
sistema desaparece y aparece el prompt del FTP, que es:
FTP>
ó
FTP-0>
A partir de este momento ya se pueden utilizar los comandos específicos del FTP.
Comandos del Cliente FTP

Salir de una sesión de FTP
Para salir de una sesión de FTP, se pueden utilizar los siguientes comandos:
close Termina la sesión de FTP, pero no sale del programa.

quit
bye Termina la sesión de FTP y sale del programa.
Obtener Ayuda
FTP posee varios comandos para obtener ayuda de cómo utilizarlo:
help
? Dá una lista de los comandos del FTP de la máquina local
Página 55
help comando Dá información sobre el comando especificado, correspondeinte a
? comando la máquina local
Manipulación de Archivos y Directorios

A continuación se da una relación de comandos del FTP referentes al manejo de archivos y directorios.
lcd directorio-local Para moverse de un directorio a otro en la máquina local

lcd unidad:
Para cambiar de una unidad de disco a otra, en el caso particular de
que la máquina local esa un PC
cd directorio-remoto Para moverse de un directorio a otro en la máquina remota
lls directorio-local Para listar el contenido de un directorio en la máquina local
dir directorio-remoto
ls directorio-remoto Para listar el contenido de un directorio en la máquina remota
! comando Para ejecutar un comando en la máquina local
delete fichero-remoto Para borrar un fichero en la máquina remota
delete ficheros-remotos Para borrar varios ficheros en la máquina remota
rmdir directorio-remoto Para borrar un directorio en la máquina remota
mkdir directorio-remoto Para crear un directorio en la máquina remota
pwd Para saber el directorio en el que se está, en la máquina remota
Transferencia de Archivos
Tipos de Transferencia
Con FTP se puede realizar la transferencia de información en dos formatos diferentes: ascii y binario. Por defecto, la
transferencia se hace en modo ascii. Para saber el tipo de formato que está activado para realizar las transferencias, se utiliza
el comando:
type
Para hacer la transferencia en formato ascii (lo hace por defecto), se utiliza el comando:
ascii
type ascii
Para hacer la transferencia en formato binario, se utiliza el comando:
binary
type binary
Transferencia Interactiva
De acuerdo a como esté configurado, el cliente FTP, puede solicitar confirmación, o no, de cada archivo que va a transferir:
esta configuración se llama Intercative Mode.
• si está en Interactive mode on, va a pedir confirmación antes de transferir cada uno de los ficheros especificados.
• si está en Interactive mode off, no va a pedir confirmación antes de transferir cada uno de los ficheros
especificados.
Para cambiar de mode on a off, o viceversa, se utiliza el comando prompt, cuya sintaxis, es simplemente:
Página 56
prompt
Transferencia de archivos desde la máquina Remota a la Local

Para transferir un fichero de la máquina remota a la local, se utiliza el comando get o recv (ambos son equivalentes). La
sintaxis es:
get archivo-remoto
ó
get
(remote-file) archivo-remoto
Si se quiere cambiar el nombre del archivo que se va a transferir, se pondrá:
get archivo-remoto archivo -local
Si se quieren transferir varios archivos de la máquina remota a la local, se utiliza el comando mget. La sintaxis es:
mget lista de nombres de archivos-remotos

ó
mget
(remote-files) lista de nombres de archivos-remotos
Nota
Los nombres de los ficheros van separados por blancos y pueden incluir los
metacaracteres “*” y “?”.
Transferencia de archivos desde la máquina Local a la Remota

Para transferir un fichero de la máquina local a la remota, se utiliza el comando put o send (ambos son equivalentes). La
sintaxis es:
put archivo-local
ó
put
(File) archivo-local
Si se quiere cambiar el nombre del archivo que se va a transferir, se pondrá:
put archivo-local archivo-remoto

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

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

Los servidores de correo realizan dos funciones diferentes
1. Relay (de posta)

2. Recolección (Collection Server)
Lo normal es que un servidor cumpla ambos roles (de ¨relay¨ y ¨collection¨). Uno puede ¨levantar¨ un servidor SMTP propio
para enviar y recibir correo pero se debe poner extremo cuidado en su configuración si no se quiere perder mails o enviar mails
incorrectamente. Es muy importante al configurar el ¨relay¨ de no permitir que cualquiera (everybody) pueda acceder a el y
usarlo como relay. Los que realizan Spam muy probablemente lo usaran y será ëse¨ 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)
Servidores de e-mail conocidos

QMail
Un servidor de correo que fue diseñado bajo las normas impuestas en los
RFC de la IETF.
URL: www.qmail.org
Costo: $0,-
QMail fue diseñado respondiendo en un 100% a los RFC (Request For

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

mundo Linux (Unix en general). Y, se instala por defecto en casi
“todas” las distribuciones.
Es conveniente saber manejar sendmail y quizas luego usar otro. Escalea muy bien y tiene un sinnumero de características,
incluyendo el soporte DNSRBL.
El mayor problema con sendmail es que su sistema de configuración está basado en ´m4’. Este es un leguaje macro no difícil
de dominar. Pero si implica que usted debe dedicarle una significativa cantidad de tiempo para descifrar cómo configurar
sendmail de una forma segura y que haga lo que usted desee. A menos que uno desee tener un sendmail muy a medida tener
que programar en m4 no es una buena opción.
Por suerte la configuración por defecto es suficientemente buena para tener un servidor de correo básico.
Página 59
Si se puede dominar m4 (a través de la documentación sendmail o uno de los numerosos libros que existen) sendmail es un
servidor muy poderoso y capaz. Como es tan popular existe una comunidad de usuarios de sendmail en internet muy grande y
conocedora capaz de ayudarnos.
Muchas distribuciones se están alejando de sendmail por sistemas más simples como Postfix y Exim.
Si usted elige sendmail, asegúrese de estar al tanto con lo último en seguridad, ya que sendmail no tiene gran fama con los
exploits. De todos modos si uno actualiza constantemente los sucesivos parches nos cubren.
Postfix
Es muy fácil de configurar y esta resultando un reemplazo para sendmail.
URL: www.postfix.org
Costo: $0
Postfix comenzó originalmente como una alternativa (de más simple

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

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

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

muy popular para Windows NT. Recientemente ha decidido
migrarlo a Linux y otras plataformas Unix.
La lista de características para GLMail son impresionantes junto a su facilidad de instalación y configuración. Es ideal para
aquel que deasea un mail server en servicio, pero no desea perder el tiempo tratando de comprender qué está haciendo. La
instalación es un proceso simple y GLMail no depende de ninguna distribución específica de Linux. Esto lo hace muy
interesante para uno que está familiarizado con un estilo particular de Linux y no desea cambiar para solo instalar su servidor
de mail. Todo es manejado a través de una interfase Web, permitiendo el control completo del servidor. Esto mantiene
escondida del administrador los detalles de configuración.
GLMail es particularmente popular por su capacidad de filtrado anti-virus y anti-spam. Es bueno bloqueando y tiene un bajo
índice de falsos positivos lo que da confianza en el sistema. De este modo los usuarios no deben preocuparse que su servidor de
mail devora sus mensajes importantes pensando que contienen algo desagradable o que son de una fuente spam.
El soporte disponible para GLMail es ciertamente muy bueno y diferentes contratos pueden ser comprados dependiendo de las
necesidades de nuestro propio negocio. Si usted está interesado en mirar a GLMail, puede bajarse un trial de 28 dias que está
disponible en su web page. Con el filtrado de spam y el virus que tiene (lo cual generalmente no está disponible al mismo nivel
con los productos de Open Source), GLMail está cerca de ser un “killer application”.
Página 61
Capítulo 6
Introducción a SendMail
La mayoría de las distribuciones de GNU/Linux incluyen de
manera predeterminada Sendmail, un poderoso servidor de correo
electrónico ampliamente utilizado alrededor del mundo. Este
requiere de una correcta configuración para su mejor
aprovechamiento y poder disponer de un nivel de seguridad
aceptable.
Es muy común que los administradores inexpertos no se molesten siquiera en establecer un nivel de seguridad apropiado en sus
redes locales, y mucho menos en el servidor de correo, el cual ven como un servicio más. Es un error común el configurar
Sendmail para que permita enviar correo como sea a cualquier costo. Usualmente este costo significa convertirse en Open
Relay, y por lo tanto en un paraíso para personas que se dedican al envío masivo de correo comercial (Spam).
Requisitos previos
• Usted tiene un dominio propio.
o Que tiene un IP permanente o estática, y no una dinámica, y que se trata de un enlace dedicado, como E1,
DSL, T1 o T3, etc. Es decir, usted NO se conecta a Internet por medio de un modem.
• Tiene perfectamente configurada su red local y parámetros de red del servidor.
o Que usted utiliza Red Hat Linux 7.2, 7.3, 8.0 o 9 o al menos Sendmail-8.11.6 y xinetd-2.3.3.
Resultados a obtener
• Enviar y recibir correo electrónico.
• Establecer un buen nivel de seguridad.
• Filtrar el molesto Spam, o correo masivo no solicitado, que a muchos nos aqueja a diario, para toda su red local.
Requerimientos mínimos
• Un servidor con al menos 32 MB RAM y alguna distribución de GNU/Linux® instalada.
• Deben de estar bien configurado los parámetros de red y un servidor de nombres -DNS-.
• Preferentemente, aunque no indispensable, deberá utilizar DOS tarjetas de red. Lo que si será obligatorio es disponer
de al menos dos interfaces. Una para acceder a la red local y otra para acceder hacia Internet (una de estas puede ser
virtual, o eth0:0, o bien una segunda interfaz real, o eth1).
• Tener instalados los paquetes sendmail, sendmail-cf, m4, make, xinet e imap que vienen incluidos en el CD de
instalación o servidor FTP de actualizaciones para la versión de la distribución que usted utilice.
Tómese en consideración que, de ser posible, se debe utilizar la versión estable más reciente de todo el software que vaya a
instalar al realizar los procedimientos descritos en este capítulo, a fin de contar con los parches de seguridad necesarios.
Ninguna versión de sendmail anterior a la 8.11.6 se considera como apropiada debido a fallas de seguridad de gran
importancia, y ningún administrador competente utilizaría una versión inferior a la 8.11.6. Por favor visite el sito Web de su
distribución predilecta para estar al tanto de cualquier aviso de actualizaciones de seguridad. Ejemplo: para Red Hat Linux 7.2,
7.3, 8.0 y 9 hay paquetes de actualización en los siguientes enlaces:
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.
Verificando parámetros de red

Debe de definirse el nombre de la máquina que funcionará como servidor de correo. Normalmente utilizaremos el esquema
nombre_maquina.nombre_dominio. Un ejemplo del nombre de la máquina servidor sería linux.mi-dominio.org o
servidor.mi-dominio.org. Así que asegúrese de que esto se encuentra perfectamente definido en
/etc/sysconfig/network y /etc/hosts:
Para /etc/sysconfig/network, es decir, el nombre que asignamos a la máquina, correspondería lo siguiente:
NETWORKING=yes
HOSTNAME=servidor.mi-dominio.org
GATEWAY=148.243.59.254
Para /etc/hosts, es decir, la información de los hosts y las direcciones IP, correspondería lo siguiente:
# Primero, verificamos que las direcciones IP del servidor estén asociadas

# correctamente a un nombre largo y uno corto.
127.0.0.1 localhost.localdomain localhost
148.243.59.1 servidor.mi-dominio.org servidor
192.168.1.1 intranet.mi-red-local.org intranet
#
# Opcionalmente aquí puede agregar también los nombres
# y direcciones IP de la máquinas de la red local.
192.168.1.2 maquina2.mi-red-local.org maquina2
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.
Página 63
Cuidado
Se requiere un DNS perfectamente configurado para que este resuelva su nombre
de dominio utilizado por el servidor de correo. Recuerde que el correo
proveniente de otros equipos no llega solo al servidor ni tampoco por arte de
magia.
Confirmando la instalación de Sendmail

Es importante tener instalados los paquetes sendmail y sendmail-cf, ya que utilizaremos el servidor de correo Sendmail
para el envío de nuestros mensajes y filtrado de correo masivo no solicitado -Spam-, y el paquete imap, mismo que nos
permitirá utilizar el servicio de IMAP y POP3. Para asegurarse de esto, se puede utilizar la siguiente línea de comando:
rpm -q sendmail sendmail-cf imap
Esto debe devolvernos las versiones de sendmail, sendmail-cf e imap que se tienen instaladas. Si no fuese así, debemos
cambiar a root, si aún no lo hemos hecho, y proceder a instalar estos paquetes. Introduzca el CDROM de su distribución y siga
el siguiente procedimiento:
mount /mnt/cdrom
cd /mnt/cdrom/RedHat/RPMS
rpm -Uvh sendmail-* imap-*
cd $home
eject /mnt/cdrom
Debe instalar sendmail-cf o no le será posible compilar los archivos necesarios para configurar Sendmail. El paquete imap,
el cual contiene el daemon para los protocolo POP3, es el que nos permitirá recuperar el correo desde el servidor en el resto de
las máquinas que integren la red local con cualquier cliente de correo electrónico.
Configurando Sendmail
Antes de continuar, debemos editar el fichero /etc/mail/local-host-names, en el cual deberemos de listar todos y cada
uno de los aliases que tenga el servidor que estamos configurando, así como los posibles sub-dominios. Es decir, todos los
dominios para los cuales estaremos recibiendo correo en un momento dado.
# Incluya aquí todos los dominios para los que reciba correo.
#
mi-dominio.org
servidor.mi-dominio.org
mail.mi-dominio.org
mi-red-local.org
intranet.mi-red-local.org
mail.mi-red-local.org
Procederemos entonces a modificar el archivo /etc/mail/sendmail.mc, con previo respaldo del original, a fin de preparar
la configuración del servidor de correo.
cp /etc/mail/sendmail.mc /etc/mail/etc/sendmail.mc.default
Por defecto Sendmail solo permitirá enviar correo solo desde la interfaz loopback (127.0.0.1), es decir, desde el mismo
servidor. Si queremos poder enviar correo desde las máquinas de la red local comente la línea o bien, si tiene varias, añada las
interfaces desde las cuales se quiere que escuche peticiones sendmail y omita las que no deben, como sería una red local
secundaria con restricciones.
dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
Página 64
Si queremos filtrar Spam de manera eficiente, la mejor manera de empezar a hacerlo es rechazando correo proveniente de
dominios NO RESUELTOS, es decir dominios que no están registrados en un DNS y que por lo tanto SON inválidos. Para tal
fin, a menos que se requiera lo contrario, es necesario mantener comentada la siguiente línea:
dnl FEATURE(àccept_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(ÙUCP_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(ÀLIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/var/log/sendmail.st')dnl
define(ÙUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', àuthwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', À')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(àccess_db')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
dnl FEATURE(`relay_based_on_MX')dnl
FEATURE(dnsbl, `blackholes.mail-abuse.org', `Rejected - see www.mail-abuse.org/rbl/')dnl
FEATURE(dnsbl, `dialups.mail-abuse.org', `Rejected - see www.mail-abuse.org/dul/')dnl
FEATURE(dnsbl, `relays.mail-abuse.org', `Rejected - see work-rss.mail-abuse.org/rss/')dnl
FEATURE(`delay_checks')dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
MASQUERADE_AS(mi-dominio.org)dnl
Configuración recomendada de Sendmail.mc para Red Hat Linux 8.0 y 9
divert(-1)dnl
Página 65
dnl #
dnl # This is the sendmail macro config file for m4. If you make changes to
dnl # /etc/mail/sendmail.mc, you will need to regenerate the
dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is
dnl # installed and then performing a
dnl #
dnl # make -C /etc/mail
dnl #
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for Red Hat Linux')dnl
OSTYPE(`linux')dnl
dnl #
dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #
dnl define(`SMART_HOST',`smtp.your.provider')
dnl #
define(`confDEF_USER_ID',``8:12'')dnl
define(`confTRUSTED_USER', `smmsp')dnl
dnl define(`confAUTO_REBUILD')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(ÀLIAS_FILE', `/etc/aliases')dnl
dnl define(`STATUS_FILE', `/etc/mail/statistics')dnl
define(ÙUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', àuthwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', À')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', À 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(ÈXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl define(`confAUTH_MECHANISMS', ÈXTERNAL 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(àccess_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 #
dnl FEATURE(`relay_based_on_MX')dnl
dnl #
dnl # Also accept email sent to "localhost.localdomain" as local email.
dnl #
LOCAL_DOMAIN(`localhost.localdomain')dnl
dnl #
dnl # The following example makes mail from this host and any additional
dnl # specified domains appear to be sent from mydomain.com
dnl #
MASQUERADE_AS('mi-dominio.org')dnl
dnl #
dnl # masquerade not just the headers, but the envelope as well
dnl #
FEATURE(masquerade_envelope)dnl
dnl #
dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well
dnl #
dnl FEATURE(masquerade_entire_domain)dnl
dnl #
dnl MASQUERADE_DOMAIN(localhost)dnl
dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl
dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl
dnl MASQUERADE_DOMAIN(mydomain.lan)dnl
Página 67
FEATURE(dnsbl, `blackholes.mail-abuse.org', `Rejected - see www.mail-abuse.org/rbl/')dnl
FEATURE(dnsbl, `dialups.mail-abuse.org', `Rejected - see www.mail-abuse.org/dul/')dnl
FEATURE(dnsbl, `relays.mail-abuse.org', `Rejected - see work-rss.mail-abuse.org/rss/')dnl
FEATURE(`delay_checks')dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
Luego se procesa con el siguiente comando para generar /etc/sendmail.cf (Red Hat Linux 7.x) o
/etc/mail/sendmail.cf (Red Hat Linux 8.0 y 9):
Procedimiento en Red Hat Linux 7.x

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

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Deben definirse los dominios para los cuales se estará permitiendo enviar correo electrónico. Esto se hace generando el archivo
/etc/mail/relay-domains:
mi-dominio.org.mx
servidor.mi-dominio.org.mx
mi-red-local.org.mx
intranet.mi-red-local.org.mx
Abrimos ahora el archivo /etc/mail/access y agregamos algunas líneas para definir quienes podrán hacer uso de nuestro
servidor de correo para poder enviar mensajes:
# Por defecto, solo se permite enviar correo desde localhost...

localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY
# Debemos añadir solo las direcciones IP que ahora tenga el servidor

#
192.168.1.1 RELAY
148.243.59.1 RELAY
#
# Agregue también las direcciones IP que integran su red local.
# Solo especifique aquellas máquinas que tendrán permitido enviar
# y recibir correo. No es buena idea especificar redes completas.
# Especifique máquinas individuales, aunque signifique ingresar
# manualmente un centenar de entradas. Es más seguro de este modo.
#
192.168.1.2 RELAY
192.168.1.3 RELAY
192.168.1.4 RELAY
# etc.
#
# Y también podemos agregar las direcciones de correo electrónico
# de aquellos a quienes consideremos"indeseables", o que queramos
# bloquear.
Spam@algun_Spamer.com REJECT
info@otro_Spammer.com REJECT
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
O bien puede ejecutar lo siguiente:
makemap hash /etc/mail/access.db < /etc/mail/access
Será de utilidad designar un alias a la cuenta de correo de root a fin de recibir los mensajes generados por el sistema en una
cuenta común de usuario. Abra el archivo /etc/aliases, en donde al final encontrará las siguientes líneas:
# Person who should get root's mail

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

root: jperez
A fin de que este nuevo alias surta efecto y pueda ser utilizado por Sendmail debe utilizar el comando newaliases:
newaliases
Terminados los detalles de la configuración, reinicie sendmail del siguiente modo y tendrá listo un servidor de correo que
podrá utilizar para enviar mensajes para toda su red local utilizando el servidor SMTP de su proveedor de servicios:
service sendmail restart
Generalmente Sendmail está incluido entre los servicios que de forma predeterminada se inician con el sistema. Si por alguna
razón Sendmail no estuviese habilitado, ejecute lo siguiente a fin de habilitar sendmail en los niveles de corrida 3, 4 y 5:
chkconfig --level 345 sendmail on
Si está funcionando un firewall, recuerde que debe de estar abierto el puerto 25, de otro modo el correo saldría pero no entraría.
Añada o verifique que esté presente una línea en el guión de firewall similar a la siguiente:
# SMTP
iptables -t filter -A INPUT -p tcp -s 0/0 -d 0/0 --dport 25 -j ACCEPT
Habilitando los servicios POP3 e IMAP

Si usted utiliza Red Hat Linux 7.x o versiones posteriores o equivalentes, debe saber que inetd ha sido sustituido por xinetd, y
utiliza métodos de configuración muy distintos.
Puede habilitar los servicios ipop3 (POP3 tradicional, autenticación en texto plano), pop3s (POP3 seguro, autenticación con
criptografía), imap (IMAP tradicional, autenticación en texto plano) e imaps (IMAP seguro, autenticación con criptografía).
Utilice aquellos que considere como más apropiados para su red local de acuerdo a las capacidades de los clientes de correo
electrónico utilizados. Tome en cuenta que la autenticación por medio de texto plano es definitivamente un método inseguro, y
siempre serán mejor usar los servicios que permitan establecer conexiones seguras.
Página 69
Puede habilitar los servicios de manera automática e inmediata ejecutando los siguientes comandos (solo habilite aquellos que
realmente necesite):
chkconfig 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
}
Lo mismo aplica para el protocolo IMAP e IMAPS.

Hecho lo anterior, es necesario reiniciar el daemon xinetd con la siguiente línea de comando:
service xinet restart
¿Que hacer con el Spam?

Sin duda alguna una de las cosas más molestas de Internet es el correo comercial no solicitado, comúnmente llamado Spam.
Las empresas que incurren en esta forma de marketing no tienen el mínimo respeto por los demás, y saturan cientos de miles de
buzones de correo a diario. Las empresas que incurren en este tipo de promoción deberían ser boicoteadas y los responsables de
enviar el correo deberían ser apedreados públicamente. Veremos un método civilizado para combatirlos.
No importa cuanto se queje uno, o cuantos mensajes con insultos y llamada telefónicas reclamo se hagan a las oficinas de las
empresas que incurren en esta poco ética forma de promoción, estas gentes no les interesa la opinión de a quienes ellos
perjudican haciendo malgastar el ancho de banda o bloqueando servidores de correo. Ellos compran y hacen uso sin
autorización de discos con cientos de miles de direcciones correo electrónico con un solo objetivo: promocionar como sea
productos y servicios, en su mayoría, inútiles.
El combate al Spam requiere de al colaboración de los administradores de las redes, quienes deben atender y dar seguimiento a
las quejas y tomar las acciones ejemplares pertinentes. Los usuarios deben participar reportando incidentes a los
administradores de las redes involucradas.
Empresas que, por alguna razón, y gracias a lagunas legales, recurren al envío de Spam, pueden ser bloqueadas por completo
añadiendo una entrada que rechace correo generado por los servidores de empresas que incurran en Spam. Esto se hace
editando /etc/mail/access y generando /etc/mail/access.db. Ejemplo:
newlad.com REJECT
propnewidea.com REJECT
lapromocion.com REJECT
hosting.com REJECT
solopromos.com REJECT
Página 70
Acto seguido se ejecuta el siguiente comando:
makemap hash /etc/mail/access.db < /etc/mail/access
Y se reinicia Sendmail. En adelante todo correo enviado desde los dominios anteriormente mencionados, será rechazado por
completo para toda nuestra red.
Otra opción más del administrador es bloquear también el acceso a los dominios involucrados a través de IPChains o
IPTables. Esto no impedirá que llegue correo, pero servirá para boicotear a las empresas que utilizan Spam para
promocionarse, al no permitir el acceso a sus redes desde nuestras redes locales.
Para determinar la dirección IP de un dominio en particular, solo baste ejecutar el comando host, el cual devolverá la dirección
IP y quizá algo de información adicional, como si se trata del alias de otro dominio.
# host solopromos.com
solopromos.com. has address 200.57.146.18
Una vez determinadas las direcciones IP problemáticas, solo hay que añadir algunas líneas en el guión de Firewall que se este
utilizando de modo tal que queden bloqueadas de manera permanente, por lo menos desde nuestra red local. Ejemplo:
iptables -A INPUT -s 216.219.236.81 -d 0/0 -j DROP

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

Si el servidor DNS se localiza en otro servidor y es administrado por otras personas, solo bastará con informar al administrador
de dicho servidor de nombres la existencia del nuevo servidor de correo electrónico, a fin de que se de de alta la entrada
correspondiente en el DNS y a su vez a fin de que el NIC lo tome en cuenta en el siguiente ciclo de refresco.
Si desea configurar DNS propio, y dar éste de alta con el NIC, se necesitará tener instalados los siguientes paquetes: bind, bind-
utils y caching-nameserver. Todos, seguramente, vienen incluidos en alguno de los CD de instalación. Note por favor que no es
conveniente utilizar versiones anteriores a bind-9.1.3, debido a serias fallas de seguridad. Consulte en el sitio Web de su
distribución para verificar si hay paquetes de actualización disponibles.
Nota
Para información detallada de cómo instalar, configurar y mantener un servidor
DNS, vea el LOC 1-2-3, Capítulo 13.
Página 71
Configuración de los clientes de correo
Considerando que tiene bien
configurada su red local y que ha
seguido este capítulo al pie de la
letra, sea la PC que sea en su red
local, puede configurar
mail.mi-red-local.org o
mail.mi-dominio.org como
servidor de correo saliente o
SMTP y servidor de correo
entrante, POP3 o IMAP, en el
cliente de correo que utilice.
Figura 1 - Preferencias de Netscape para los servidores de correo
Página 72
Capítulo 7
Introducción a Horde (WebMail)
¿Qué es Horde?
Horde es un programa (software) y un proyecto. El Proyecto
Horde comprende un conjunto de aplicaciones basada en Web
(Web based) de productividad, mensajería, y administración de
proyectos. Detalle de estas están descritas más adelante.
El Horde Framework es un código de base común a todas las aplicaciones Horde, incluyendo librerías y un ainterfase de
usuario común a ellas. Horde y sus componentes están escritos en PHP. El proyecto Horde (www.horde.org) tiene una gran
cantidad de componentes donde se destacan: IMP, Turba, Kronolith, Jonah, WHUPS, Chora y Gollem.
¿Qué es IMP?
IMP es Internet Messaging Program (antiguamente era, entre otras cosas, IMAP webMail Program), un sistema webmail
basado en PHP y componente del proyecto Horde. IMP es el más maduro de los componentes de Horde, y es el más
ampliamente desarrollado (¡hasta ahora!). IMP, una vez instalado, accede al mail a través de IMAP, requiriendo poca a
ninguna preparación especial en el servidor en el cual se almacena el correo.
IMP ofrece muchas de las características que los usuarios esperan de sus programas de mails convencionales, incluyendo
anexos, corrector ortográfico, múltiples carpetas, y soporte de múltiples lenguajes.
¿Qué es Turba?
Turba es la libreta de direcciones y administrador de contactos de Horde. Reemplaza el simple administrador de contactos que
fue parte de versiones anteriores de IMP.
¿Qué es Kronolith?
Kronolith es un calendario y organizador diario (think Day-Timer) basado en la web.
¿Qué es Jonah?
Jonah es un administrador de contenidos y presentaciones basado en PHP y diseñado para manejar un sitio tipo portal usando
RDF, RSS y contenido de segundo plano XML. Sigue en la fase de desarrollo.
¿Qué es WHUPS?
WHUPS es el Web-based Horde Unified Project System. Esta basado en PHP y es un sistema de administración de proyectos.
WHUPS implementa un sistema muy flexible de rastreo de fuentes, y en el futuro estará integrado por Chora y otro
desarrollados de Horde relacionados con desarrrollo y administración proyectos.
¿Qué es Chora?
Chora es una aplicación para ver repositorios de código que son manejados usando el sistema de control de fuente (source code
system) CVS. Provee una vista, basada en la web, de cualquier repositorio CVS. Ahora incluye de soporte anotaciones, Visual
Branco Beijing y diffs legibles por humanos.
¿Qué es Gollem?
Gollem es el administrador de archivos de Horde, y provee una interfase común para acceder a los sitios FTP, sistema de
almacenamiento local de archivos, y un almacenamiento de sistema de archivo SQL virtual. Todavía en desarrollo están varios
de sus componentes.
Solamente quiero WebMail. ¿Por qué necesito Horde?

Si sólo necesita la funcionalidad de un solo componente, puede simplemente instalar ese componente; sin embargo, todos los
componentes se basan en un código común en el mismo paquete Horde. Aunque instale un componente o todos los
Página 73
componentes, necesita instalar Horde. Entonces, si solo quiere ofrecer un email basado en Web (en gran medida, el uso más
común de aplicaciones Horde hasta ahora) necesitará instalar Horde e IMP.
¿Cuánto cuesta Horde?

Horde, y todos sus componentes, son gratis, siendo liberado bajo GNU Public License (Licencia Pública GNU).
¿En qué plataformas funciona Horde?

Horde está desarrollado en Unix, con el servidor web Apache. Pero debería funcionar correctamente en cualquier Unix-
GNU/Linux en el que usted pueda instalar Apache y PHP.
¿Horde funciona en Windows 95 o en NT/2K/XP?

Horde y todos los Componentes de Horde trabajan bajo Windows NT/2K/XP con Apache y PHP4 con un rendimiento
aceptable. IMP y Turba, se supone trabajan también en Windows NT/2K con IIS y PHP4.
Página 74
Capítulo 8
Introducción a Administración Remota
La administración remota siempre ha constituido un reto para los administradores de redes, para situaciones particulares dentro
y fuera de la red física en la cual están conectados los servidores. Ya sea porque la distribución física de los servidores no
permite que estén todos en un “centro de cómputos” ó porque desea administrar los servidores sin levantarse de su silla,
también para el caso que necesite administrar servidores que se encuentran en distintas sucursales ó acceder a recursos de la
empresa cuando esté de viaje o en su casa. El acceso remoto con propósitos de administración es la solución para estas
situaciones.
Diferentes tipos de Administración Remota

Desde un principio vamos a aclarar que existen distintas maneras de realizar el mismo propósito: Control Remoto, Sesión
Remota y Acceso Remoto. Todas pueden utilizarse en cualquier topología de conexión: dentro de una LAN ó a lo largo de una
conexión WAN ó simplemente por medio de Dial-Up (modem), aunque es necesario tener en cuenta las características de cada
una antes de su implementación, para evaluar sus pros y sus contras respecto de cada tipo de conexión.
Control Remoto
Las soluciones de control remoto, por definición, permiten tomar control de una PC (Workstation ó Server) extendiendo, a lo
largo del medio físico que estemos utilizando, solamente las capacidades de los dispositivos de entrada-salida (mouse, teclado y
display) de esa PC. El software que permite esto, típicamente consta de dos partes, una es la que se instala en la PC que será
controlada (host) y la otra se instala en la PC que tomará el control (remote). El tráfico de datos, sobre el medio físico, entre el
host y el remoto se reduce exclusivamente a órdenes de entrada-salida y display, todo el procesamiento y ejecución de
aplicaciones se realiza en la PC que actúa de host.
Al iniciar una conexión de control remoto sobre una PC, existe la opción de elegir qué grado de control tiene el remoto sobre
los dispositivos de entrada-salida, puede ser mínima (solamente ver el display), compartida (ver el display; dominar teclado y
mouse en forma conjunta con el host) o total (la PC host pierde el control sobre el teclado, mouse y display).
Cabe aclarar que este tipo de software muestra solamente lo que esta ocurriendo en la PC a la cual esta conectada, durante el
período de control remoto; entendiendo con esto que si hay un usuario trabajando en esa PC, se podrá “ver” absolutamente todo
lo que está haciendo. En caso de interrumpirse la conexión, la PC quedará en el estado en que se encontraba mientras se estaba
tomando control de ella, con los riesgos que esto implica (archivos y aplicaciones abiertas, etc.).
Software que permiten hacer control remoto:
Symantec pcAnywhere, VNC, GoToMyPC, RAdmin, Carbon Copy.
Sesión Remota
En todo lo que se refiera al medio físico sobre el cual se establece una sesión remota, y los datos que viajan por él, una sesión
remota comparte las características con las de Control Remoto. La PC desde la cual iniciamos una sesión remota tendrá control
de teclado, mouse y display.
Al iniciar una Sesión Remota, lo que realmente estamos haciendo es iniciar una conexión a una PC (Server) que nos permite
tener todo un entorno de trabajo (ya sea en modo texto o gráfico) dedicado a nuestra conexión. Si más de un usuario se conecta
por medio de sesiones remotas a un servidor, cada uno de los usuarios tiene su propio entorno de trabajo, capacidades
individuales de ejecución de programas, etc.
Software que permite hacer sesión remota en modo texto (TelNet, SSH, etc.):
Century TinyTERM, HummingBird Exceed, PuTTY.
Software que permite hacer sesión remota en modo gráfico:
VNC (con servidores Microsoft no es posible hacer multi-sesión grafica), Windows Terminal Services.
Salvo Windows Terminal Services, los demás protocolos y productos son cross-platform (multiplataforma).
Acceso Remoto
A diferencia de las metodologías de control remoto y sesión remota, la tecnología de acceso remoto, apunta a que el usuario se
incorpore como un nodo más a la topología existente en una red. Al hacer esto, la PC (nodo) ve todo el tráfico, y participa
activamente, de la red a la cual se está conectando. Todo el procesamiento y ejecución de aplicaciones se realiza en la PC Local
Página 75
y todo el tráfico de datos ó documentos que obtenga de las demás PCs de la red (Workstations o Servers) viajará hasta la PC
Local.
La principal restricción de esta metodología es que cuanto más lento sea el tipo de conexión, más lenta se volverá la respuesta
desde la red a la que se ha conectado.
Direcciones Web relacionadas

Carbon Copy www.codework.com
Century TinyTERM www.censoft.com
GoToMyPC www.gotomypc.com
HummingBird Exceed www.hummingbird.com/products/
PuTTY www.chiark.greenend.org.uk/~sgtatham/putty/
RAdmin www.famatech.com
Symantec pcAnywhere www.symantec.com
VNC www.realvnc.com
Windows Terminal Services www.microsoft.com
Página 76
Capítulo 9
Introducción a TelNet
El protocolo diseñado para proporcionar el servicio de conexión remota (remote login) recibe el nombre de TELNET, el cual
forma parte del conjunto de protocolos TCP/IP y depende del protocolo TCP para el nivel de transporte.
El protocolo TELNET es un emulador de terminal que permite acceder a los recursos y ejecutar los programas de un ordenador
remoto en la red, de la misma forma que si se tratara de un terminal real directamente conectado al sistema remoto. Una vez
establecida la conexión el usuario podrá iniciar la sesión con su clave de acceso. De la misma manera que ocurre con el
protocolo FTP, existen servidores que permiten un acceso libre cuando se especifica "anonymous" como nombre de usuario.
Es posible ejecutar una aplicación cliente TELNET desde cualquier sistema operativo, pero hay que tener en cuenta que los
servidores suelen ser sistemas VMS o UNIX por lo que, a diferencia del protocolo FTP para transferencia de ficheros donde se
utilizan ciertos comandos propios de esta aplicación, los comandos y sintaxis que se utilice en TELNET deben ser los del
sistema operativo del servidor. El sistema local que utiliza el usuario se convierte en un terminal "no inteligente" donde todos
los caracteres pulsados y las acciones que se realicen se envían al host remoto, el cual devuelve el resultado de su trabajo. Para
facilitar un poco la tarea a los usuarios, en algunos casos se encuentran desarrollados menús con las distintas opciones que se
ofrecen.
Los programas clientes de TELNET deben ser capaces de emular los terminales en modo texto más utilizados para asegurarse
la compatibilidad con otros sistemas, lo que incluye una emulación del teclado. El terminal más extendido es el VT100, el cual
proporciona compatibilidad con la mayoría de los sistemas, aunque puede ser aconsejable que el programa cliente soporte
emulación de otro tipo de terminales.
Telnet en Linux
En la mayoría (por no decir todas) las distribuciones linux, el servicio telnet, depende del demonio telnetd, este demonio se
“levanta” (inicia) bajo demanda. El demonio encargado de administrar el inicio y la parada del demonio telnetd, es el
demonio xinetd ó inetd (dependiendo de la distribución de linux y del kernel que tenga dicha distribución).
Nota
Para información detallada de cómo instalar, configurar y mantener el demonio
xinetd, vea el LOC 1-2-3, Capítulo 9.
Telnet en Windows 2000

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

1. Boton derecho sobre “my computer”
2. Bajo “Computer Management” vera “services and Applications”. Abralo clickeando el signo +.
3. Alli vera “services”. Clickeelo y vera los servicios disponibles sobre el panel derecho.
4. Busquemos Telnet. Haga boton derecho y busque propiedades
5. Del drop-down elija automatic.
Página 77
Para telnetear un servidor hacemos
telnet nombre_del_servidor
telnet direccion_IP
Podemos modificar el modo en que el cliente autentica. Por ejemplo que acepte nombre de usuario y password:
1. escriba en linea de comandos
tlntadmn
2. 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
Pruebe telnetear una máquina con UNIX.
Página 78
Capítulo 10
Introducción a SSH
OpenSSH es una implementación libre del
protocolo SSH (Secure Shell) que permite el acceso
remoto hacia sistemas. Su principal ventaja radica
en que se utiliza un túnel seguro para la
transmisión de datos, algo de lo que carecen
protocolos como FTP y Telnet, que son
precisamente los protocolos a reemplazar.
Software requerido.
• openssh-3.5p1-6
• openssh-clients-3.5p1-6
• openssh-server-3.5p1-6
Antes de continuar verifique siempre la existencia posibles actualizaciones de seguridad. Para Red Hat Linux 8.0 y 9 hay
paquetería de actualización en los siguientes enlaces:
Archivos de configuración
El archivo de configuración central del daemon sshd es /etc/ssh/sshd_config.
Procedimientos
Tome el editor de texto de su preferencia y edite /etc/ssh/sshd_config. A continuación analizaremos los parámetros a
modificar.
Parámetro ListenAddress
Por defecto SSHD escuchará peticiones por todas las interfaces del sistema. En algunos casos es posible que no se desee esto y
se prefiera limitar el acceso solo a través de una interfaz que solo se pueda acceder desde la red local. Para tal fin puede
establecerse lo siguiente, considerando que el servidor a configurar posee la IP 192.168.1.254:
ListenAddress 192.168.1.254
Parámetro PermitRootLogin
Este parámetro sirve para establecer si se va a permitir el acceso directo del usuario root al servidor SSH. Si se va a permitir el
acceso hacia el servidor desde redes públicas, resultará prudente utilizar este parámetro con el valor no.
PermitRootLogin no
Parámetro X11Forwarding
Este parámetro establece si se permite o no la ejecución remota de aplicaciones gráficas. Si se va a acceder hacia el servidor
desde red local, este parámetro puede quedarse con el valor yes. Si se va a permitir el acceso hacia el servidor desde redes
públicas, resultará prudente utilizar este parámetro con el valor no.
X11Forwarding yes
Página 79
Aplicando los cambios.
Sshd puede inicializarse, detenerse o reinicializarse a través de un guión similar a los del resto del sistema. De modo tal, podrá
inicializarse, detenerse o reinicializarse a través del comando service y añadirse al arranque del sistema en un nivel o niveles
de corrida en particular con el comando chkconfig.
Para ejecutar por primera vez el servicio, ejecute:
service sshd start
Para hacer que los cambios hechos a la configuración surtan efecto, ejecute:
service sshd restart
Para detener el daemon, ejecute:
service sshd stop
Por defecto sshd está incluido en todos los niveles de corrida con servicio de red. Para deshabilitar el servicio Sshd de los
niveles de corrida 2, 3, 4 y 5, ejecute:
chkconfig --level 2345 sshd off
Probando OpenSSH.
Acceso por shell.
Para acceder a través de shell hacia el servidor, basta con ejecutar desde el sistema cliente el comando ssh definiendo el
usuario a utilizar y el servidor al cual conectar:
ssh usuario@servidor
Acceso por SFTP

OpenSSH incluye además un servidor de archivos en modo seguro que permite sustituir las transferencias a través de protocolo
FTP, el cual envía todos los datos en texto simple.
Para acceder a través de SFTP hacia el servidor, basta con ejecutar desde el sistema cliente el comando sftp definiendo el
usuario a utilizar y el servidor al cual conectar:
sftp usuario@servidor
El shell es casi idéntico al de FTP y tiene las mismas funcionalidades.
Página 80

Linux Original Courseware - LX4 Advanced Network Administrator

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Linux Original Courseware - LX4 Advanced Network Administrator

Загружено:

Авторское право:

Доступные форматы

LOC: Linux Original Courseware

Figura 1: Esquema de firewall típico entre red local e internet

Política por defecto ACEPTAR.

En definitiva lo que se hace es:

Hay dos maneras de implementar un firewall:

INPUT, OUTPUT y FORWARD son los tres tipos de reglas de filtrado.

Una conexión TCP/IP empieza con el three-way-handshake:

Proteger la propia máquina

Saludo a la afición (echo)

Ojo con el orden de las reglas

echo -n Aplicando Reglas de Firewall...

## Establecemos politica por defecto

# A nuestra IP le dejamos todo

# A un diseñador le dejamos usar el FTP

# El puerto 80 de www debe estar abierto, es un servidor web.

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

# Hasta aquí el script es igual al ejemplo anterior

# El puerto 80 de www debe estar abierto, es un servidor web.

# Cerramos rango de los puertos privilegiados. Cuidado con este tipo de

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

Firewall de una LAN con salida a internet

Figura 6: Esquema de firewall típico entre red local e internet

echo -n Aplicando Reglas de Firewall...

## Establecemos politica por defecto

# Al firewall tenemos acceso desde la red local

# Ahora hacemos enmascaramiento de la red local

# Con esto permitimos hacer forward de paquetes en el firewall, o sea

## Y ahora cerramos los accesos indeseados del exterior:

# Cerramos un puerto de gestión: webmin

echo " OK . Verifique que lo que se aplica con: iptables -L -n"

# Hasta aquí el script es igual al ejemplo anterior

# Al firewall tenemos acceso desde la red local

## Ahora con regla FORWARD filtramos el acceso de la red local

# Aceptamos que vayan a puertos https

# Aceptamos que consulten los DNS

# Y denegamos el resto. Si se necesita alguno, ya avisaran

# Ahora hacemos enmascaramiento de la red local

# De aquí en adelante el script es igual al ejemplo anterior

Nuestro script completo quedaría así:

## Establecemos politica por defecto

# Al firewall tenemos acceso desde la red local

## Abrimos el acceso a puertos de correo

# Y abrimos el puerto pptpd para la ip del adsl de casa del jefe

## Ahora con regla FORWARD filtramos el acceso de la red local

# Aceptamos que vayan a puertos 80

# Aceptamos que consulten los DNS

# Ahora hacemos enmascaramiento de la red local

# Con esto permitimos hacer forward de paquetes en el firewall, o sea

## Y ahora cerramos los accesos indeseados del exterior:

# Cerramos un puerto de gestión: webmin

echo " OK . Verifique que lo que se aplica con: iptables -L -n"

¡Más difícil todavía!

## Establecemos politica por defecto

# Los accesos de un ip determinada a Terminal server se redirigen e esa

## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN

# Al firewall tenemos acceso desde la red local

## Abrimos el acceso a puertos de correo

# Y abrimos el puerto pptpd para la ip del adsl de casa del jefe

## Ahora con regla FORWARD filtramos el acceso de la red local

# Aceptamos que vayan a puertos 80

# Aceptamos que consulten los DNS

# Y denegamos el resto. Si se necesita alguno, ya avisaran

# Ahora hacemos enmascaramiento de la red local

# Con esto permitimos hacer forward de paquetes en el firewall, o sea