Instalación del Servidor Proxy TIS

El fichero netperm-table

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.

El fichero /etc/services

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