El TIS FWTK se puede conseguir en http://www.tis.com/research/software/.
No cometa el mismo error que yo cometí. Cuando transfiera los archivos desde TIS, LEA EL APARTADO "LÉAME". El TIS fwtk se encuentra bloqueado en un directorio oculto de su servidor.
TIS requiere que lea sus condiciones en http://www.tis.com/research/software/fwtk_readme.html y luego envíe un e-mail a fwtk-request@tislabs.com con la palabra accepted en el cuerpo del mensaje para conocer el nombre del directorio oculto. No es necesario que escriba ningún asunto en el mensaje. Posteriormente, su sistema le enviará el nombre del directorio (válido durante 12 horas) para descargar la fuente.
La versión 2.1. del FWTK resulta más fácil de compilar que cualquier versión previa.
La versión 2.1 del FWTK se compila mucho más fácilmente que cualquiera de las versiones anteriores.
Ejecute make ahora.
Ejecute make install.
El directorio de la instalación por defecto es /usr/local/etc. Podría cambiarlo a un directorio más seguro. Yo opté por cambiar el acceso a este directorio por chmod 700.
Por último, sólo queda configurar el cortafuegos.
Ahora es cuando realmente empieza lo divertido. Debemos enseñar al sistema a denominar a estos nuevos servicios y a crear las tablas para controlarlos.
No voy a intentar rescribir aquí el manual de TIS FWTK. Le mostraré la configuración que encontré hecha y explicaré los problemas que me surgieron y cómo los solucioné.
Los archivos que componen estos controles son tres:
/etc/services
Le dice al sistema en qué puertos se encuentra un servicio.
/etc/inetd.conf
Le dice a inetd a qué programa llamar cuando alguien intenta conectarse a un puerto de servicio.
/usr/local/etc/netperm-table
Le dice a los servicios FWTK a quién admitir y a quién denegar el servicio.
Para conseguir que el FWTK funcione, debe editar estos archivos de abajo hacia arriba. Editar el archivo de servicios sin haber configurado correctamente el archivo inetd.conf o netperm-table, podría hacer su sistema inaccesible.
Este archivo controla quién puede acceder a los servicios del TIS FWTK. Debería pensar en el tráfico y usar el cortafuegos desde ambos lados. La gente que se encuentre fuera de su red debería identificarse antes de poder tener acceso, y la que se encuentre dentro podría acceder directamente.
Para que la gente pueda identificarse, el cortafuegos utiliza un program llamado authsrv para tener una base de datos con los números de identificación (IP) y contraseñas de los usuarios. La sección de autenticación de netperm-table controla dónde se guarda la base de datos y quién puede tener acceso a ella.
Tuve algunos problemas a la hora de cerrar el acceso a este servicio. Observe que la entrada premit-hosts que muestro usa un *' para dar acceso a cualquiera. Si consigue que funcione, la configuración correcta para esta línea es '' authsrv: premit-hosts localhost.
# # Tabla de configuración del proxy # # Reglas de autenticación de clientes y servidores authsrv: database /usr/local/etc/fw-authdb authsrv: permit-hosts * authsrv: badsleep 1200 authsrv: nobogus true # Client Applications using the Authentication server *: authserver 127.0.0.1 114 |
Para iniciar la base de datos debe hacerlo desde el usuario root y ejecutar ./authsrv en el directorio /var/local/etc para crear el registro administrativo del usuario. A continuación tiene un ejemplo de una sesión.
Lea la documentación FWTK para aprender a añadir usuarios y grupos.
#
# authsrv
authsrv# list
authsrv# adduser admin "Auth DB admin"
ok - user added initially disabled
authsrv# ena admin
enabled
authsrv# proto admin pass
changed
authsrv# pass admin "plugh"
Password changed.
authsrv# superwiz admin
set wizard
authsrv# list
Report for users in database
user group longname ok? proto last
------ ------ ------------------ ----- ------ -----
admin Auth DB admin ena passw never
authsrv# display admin
Report for user admin (Auth DB admin)
Authentication protocol: password
Flags: WIZARD
authsrv# ^D
EOT
# |
Los controles de la puerta de enlace telnet (tn-gw), son muy sencillos y son los primeros que debería instalar.
En mi ejemplo, dejo que el sistema que se encuentra en la red privada tenga acceso sin tener que identificarse (permit-hosts 19961.2.* -passok), pero el resto de los usuarios deben introducir su número de identificación y contraseña para poder usar el proxy (permit-hosts * -auth)
También dejo que otro sistema aparte (192.1.2.202) tenga acceso directo al cortafuegos sin tener que pasar por éste. Existen dos líneas inetacl-in.telnetd para hacerlo. Más tarde explicaré cómo se llaman estas líneas.
El intervalo de espera (timeout) de Telnet deberá ser corto.
# telnet gateway rules:
tn-gw: denial-msg /usr/local/etc/tn-deny.txt
tn-gw: welcome-msg /usr/local/etc/tn-welcome.txt
tn-gw: help-msg /usr/local/etc/tn-help.txt
tn-gw: timeout 90
tn-gw: permit-hosts 192.1.2.* -passok -xok
tn-gw: permit-hosts * -auth
# Only the Administrator can telnet
# directly to the Firewall via Port 24
netacl-in.telnetd: permit-hosts 192.1.2.202 \
-exec /usr/sbin/in.telnetd |
Las órdenes que empiezan con la letra r- funcionan de la misma manera que telnet.
# rlogin gateway rules:
rlogin-gw: denial-msg /usr/local/etc/rlogin-deny.txt
rlogin-gw: welcome-msg /usr/local/etc/rlogin-welcome.txt
rlogin-gw: help-msg /usr/local/etc/rlogin-help.txt
rlogin-gw: timeout 90
rlogin-gw: permit-hosts 192.1.2.* -passok -xok
rlogin-gw: permit-hosts * -auth -xok
# Only the Administrator can telnet
#directly to the Firewall via Port
netacl-rlogind: permit-hosts 192.1.2.202 \
-exec /usr/libexec/rlogind -a |
No debería permitir que nadie, incluyendo el FTP, acceda directamente a su cortafuegos; por lo tanto, no le ponga un servidor FTP.
Una vez más, la línea de acceso de los sitemas principales permite que cualquiera que se encuentre en la red protegida tenga libre acceso a Internet, mientras que los demás deben identificarse. Incluí el registro de cada fichero enviado, así como los que recibí en mis controles. (-log { retr stor })
El intervalo de espera ftp controla el tiempo que tardará en cortarse una mala conexión, así como el tiempo que se mantendrá abierta la conexión sin que sea usada.
# ftp gateway rules:
ftp-gw: denial-msg /usr/local/etc/ftp-deny.txt
ftp-gw: welcome-msg /usr/local/etc/ftp-welcome.txt
ftp-gw: help-msg /usr/local/etc/ftp-help.txt
ftp-gw: timeout 300
ftp-gw: permit-hosts 192.1.2.* -log { retr stor }
ftp-gw: permit-hosts * -authall -log { retr stor } |
La web, el gopher y el navegador basado en el ftp se modifican con el http-gw. Las dos primeras líneas crean un directorio para almacenar el ftp y los documentos de la web a medida que pasan por el cortafuegos.Estos ficheros los creo bajo una raíz y los coloco en un directorio al que sólo se puede acceder a través de esa raíz.
La conexión a la web deberá ser corta. Controla el tiempo que tendrá esperar el usuario en el transcurso de una mala conexión.
# www and gopher gateway rules:
http-gw: userid root
http-gw: directory /jail
http-gw: timeout 90
http-gw: default-httpd www.afs.net
http-gw: hosts 192.1.2.* -log { read write ftp }
http-gw: deny-hosts * |
Realmente, la ssl-gw es una puerta de enlace. Tenga cuidado con esto. En este ejemplo dejo que cualquiera que se encuentre en la red protegida se conecte a cualquier servidor externo a la red, excepto a las direcciones 127.0.0.* y 192.1.1.*, y sólo de los puertos del 443 al 563. Los puertos del 443 al 563 se conocen como puertos SSL.
# ssl gateway rules:
ssl-gw: timeout 300
ssl-gw: hosts 192.1.2.* \
-dest { !127.0.0.* !192.1.1.* *:443:563 }
ssl-gw: deny-hosts * |
A continuación hay un ejemplo sobre cómo usar la conexión gw para permitir las conexiones a un servidor de noticias. En este ejemplo, dejo que cualquiera que se encuentre dentro de la red protegida se conecte a un solo sistema y a su puerto de noticias.
La segunda línea permite al servidor de noticias transferir sus datos a la red protegida.
Dado que la mayoría de clientes permanecen conectados mientras el usuario lee los datos, el intervalo de espera de un servidor de datos deberá ser largo.
# NetNews Pluged gateway plug-gw: timeout 3600 plug-gw: port nntp 192.1.2.* -plug-to 24.94.1.22 -port nntp plug-gw: port nntp 24.94.1.22 -plug-to 192.1.2.* -port nntp |
La puerta de enlace finger es sencilla. Cualquiera que se encuentre en la red protegida debe, en primer lugar, acceder al sistema y, posteriormente, nosotros le permitimos usar el programa finger, que se localiza en el cortafuegos. Los demás tan solo recibirán un mensaje como el siguiente:
# Enable finger service
netacl-fingerd: permit-hosts 192.1.2.* \
-exec /usr/libexec/fingerd
netacl-fingerd: permit-hosts * -exec /bin/cat \
/usr/local/etc/finger.txt |
No he instalado los servicios de Mail y X-windows, así que no voy a dar ejemplos. Si alguien tiene un ejemplo, le agradecería que me enviase un e-mail.
Aquí es donde empieza todo. Cuando un cliente se conecta al cortafuegos, éste se conecta a un puerto desconocido (inferior al 1024); por ejemplo, telnet se conecta al puerto 23. El demonio de inetd verifica esta conexión y busca el nombre del servicio en el fichero /etc/services. Luego llama al programa que tiene asignado este nombre en el fichero /etc/inetd.conf.
Algunos de los servicios que estamos creando no suelen encontrarse en el fichero /etc/services. Puede asignar algunos al puerto que desee; por ejemplo, he asignado el del administrador telnet (telnet-a) al puerto 24. Si hubiese querido, podría haberle asignado el puerto 2323. Para que el administrador (USTED) se conecte directamente al cortafuegos, tendrá que realizar una conexión telnet al puerto 24 y no al 23, y si instala su fichero netperm-table, como yo lo hice, sólo podrá hacerlo desde uno de los sistemas que se encuentran en su red protegida.
telnet-a 24/tcp ftp-gw 21/tcp # this named changed auth 113/tcp ident # User Verification ssl-gw 443/tcp |