Caso de Estudio: AuthPF

Caso de Estudio: AuthPF Autores: Jonathan Waldo, Anderson Linares. Correo electrónico de contacto: anderson.linares@gmail.com Fecha de creación : 08/06/10 Ultima modificación: 15/06/10 Índice de contenido 1.Licencia (BSD)...1 2.Problema a resolver...2 2.1.Diagrama de red...2 2.2.Definiendo las reglas...2 3. Solución...3 3.1 Configurando las interfaces de red...3 3.2 Habilitar el reenvío de paquetes...4 3.3 Habilitar PF y SSH...4 3.4 Implementación de las reglas...4 4. Pruebas...8 4.1 Concepto...8 4.2 Probando con un usuario no autenticado...8 4.3 Probando con un usuario autenticado...9 5. Conclusiones...10 6. Enlaces relacionados...10 1. Licencia (BSD) Copyright (c) Jonathan Waldo, Anderson Linares All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the OpenBSD Colombia nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 1.Licencia (BSD) 1/11

PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 2. Problema a resolver Se necesita crear una red segmentada donde se realice un proceso de autenticación previo a la utilización de los recursos vitales de la compañía, y en donde un usuario común que desee utilizar los servicios de conexión tenga acceso mínimo a la red con restricciones como por ejemplo la NO visualización de los servicios internos de la compañía. NOTA: Cuando nos referimos a un acceso mínimo estamos hablando desde no poder hacer ping a nivel de red local tratando de enumerar equipos, hasta no hacer ataques de fuerza bruta a servicios como SSH. 2.1. Diagrama de red 2.2. Definiendo las reglas Fig 1. Topología de Ejemplo La definición de las reglas son la base fundamental del filtrado, donde definimos que es lo que se va a permitir y lo que por el contrario no queremos que se permita. Se debe permitir la conexión de la red WLAN al puerto SSH (22) para la previa autenticación. Los equipos conectados a la red WLAN, tendrán acceso a internet. Los equipos conectados a la red WLAN no tendrán acceso a la red LAN. Los equipos conectados a la red WLAN que se han autorizados tendrán acceso a la LAN. 2.Problema a resolver 2/11

Se debe hacer NAT sobre la interfaz WAN para posteriormente permitir la salida de las demás interfaces hacia INTERNET. No se permitirán ataques de fuerza bruta al protocolo SSH del gateway. 3. Solución 3.1 Configurando las interfaces de red Antes de todo es necesario estar seguro que nuestro sistema reconoce nuestras interfaces de red, después de ello configuramos las tres interfaces con una dirección estática como se muestra a continuación. Tarjeta WAN: echo inet 192.168.30.1 255.255.255.0 > etc/hostname.sis0 Tarjeta LAN: echo inet 192.168.50.1 255.255.255.0 > etc/hostname.rl0 Tarjeta WLAN: echo inet 192.168.40.1 255.255.255.0 > etc/hostname.rl1 Para verificar si todo ha salido correctamente digitamos el siguiente comando. bash-3.2#ifconfig sis0: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500 lladdr 00:07:95:dd:72:b4 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::207:95ff:fedd:72b4%sis0 prefixlen 64 scopeid 0x1 inet 192.168.30.1 netmask 0xffffff00 broadcast 192.168.30.255 rl0: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500 lladdr 00:c0:a8:7a:f5:c1 priority: 0 3. Solución 3/11

media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::2c0:a8ff:fe7a:f5c1%rl0 prefixlen 64 scopeid 0x2 inet 192.168.40.1 netmask 0xffffff00 broadcast 192.168.40.255 rl1: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500 lladdr 00:08:a1:85:de:c4 priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::208:a1ff:fe85:dec4%rl1 prefixlen 64 scopeid 0x3 inet 192.168.50.1 netmask 0xffffff00 broadcast 192.168.50.255 3.2 Habilitar el reenvío de paquetes Lo que se busca principalmente es lograr una comunicación interna entre tarjetas de red, para establecer el intercambio de paquetes de forma efectiva entre las mismas. En el archivo /etc/sysctl.conf se edita la variable net.inet.ip.forwarding, pasandola de 0 a 1. #vi /etc/sysctl.conf net.inet.ip.forwarding=1 3.3 Habilitar PF y SSH Para habilitar Packet Filter modificamos el archivo /etc/rc.conf y buscamos la variable pf que por defecto se encuentra en NO y la cambiamos por YES y para habilitar SSH solo debemos quitar el NO y dejarlo con dos comillas dobles. pf=yes sshd_flags= 3.4 Implementación de las reglas A continuación se implementaran las reglas definidas con antelación en el siguiente archivo: /etc/pf.conf bash-3.2# vi /etc/pf.conf # $OpenBSD: pf.conf,v 1.49 2009/09/17 06:39:03 jmc Exp $ 3. Solución 4/11

# # See pf.conf(5) for syntax and examples. #Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1 #let skip on lo #definimos la interfaces con macros lan="rl0" ap="rl1" externa="sis0" #definimos con macros los puertos permitidos puertos_permitidos="{ftp, ftp-data, ssh, 53, http, https}" #definimos la red con macros mi_red="192.168.0.0/16" #Las tablas dinámicas para authpf y el blocker de ssh table <authpf_users> persist table <ssh_abuse> persist #Agregamos el anchor del authpf, es importante hacerlo en este lugar. anchor "authpf/*" in on $ap #Si alguien ya esta reportado, entonces bloqueelo block in quick from <ssh_abuse> #Si alguien se pasa de la raya (muchas conexiones) agreguelo a la lista negra pass in quick log on $ap proto tcp to any port ssh flags S/SA keep state \ (max-src-conn 5, max-src-conn-rate 3/5, overload <ssh_abuse> flush) antispoof for $ap block in log from no-route to any block in log from urpf-failed to any #aquí se hace el enmascaramiento, la regla dice: haga NAT en la #interfaz externa (sis0) siempre y cuando los paquetes vengan de una red que #no sea la externa y vayan para cualquier lugar match out on $externa inet from!($externa:network) to any nat-to ($externa:0) 3. Solución 5/11

anchor "ftp-proxy/*" pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021 # Reglas por defecto #Deje conectar al ssh del firewall, necesario para authpf pass in quick on $ap proto tcp from any to port {8021, ssh } #permita hacer pings para todos lados, excepto nuestra red pass in log quick on $ap proto icmp from any to!$mi_red #permita hacer resolución dns en nuestra red pass in quick on $ap proto {udp, tcp} from any to!$mi_red port 53 #Solo permita acceder a Internet en algunos puertos pass in quick on $ap proto tcp from any to!$mi_red port $puertos_permitidos #Bloquee todo lo que venga desde la wifi block in quick on $ap #Si supera el resto de filtros, dejelo pasar pass # to establish keep-state 3.5 Creando usuarios para authpf Para poder crear los usuarios que van a ser autenticados, lo hacemos con el comando adduser, haciendo referencia a la clase authpf que es la que nos va a dar el perfil definitivo para dicho usuario, es de anotar que este usuario no será un usuario común y corriente, puesto que no tendrá un shell común. Para ello primero debemos crear los siguientes directorios y archivos de la siguiente manera. #touch /etc/authpf/authpf.conf Ahora agregamos un usuario al sistema como se muestra a continuación #adduser Use option ``-silent'' if you don't want to see all warnings and questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. 3. Solución 6/11

Don't worry about mistakes. There will be a chance later to correct any input. Enter username []: prueba Enter full name []: prueba A Enter shell csh ksh nologin sh [ksh]: Uid [1002]: Login group prueba [prueba]: Login group is ``prueba''. Invite prueba into other groups: guest no [no]: Login class authpf daemon default staff [default]: authpf Enter password []: Enter password again []: Name: prueba Password: **** Fullname: prueba A Uid: 1002 Gid: 1002 (prueba) Groups: prueba Login Class: authpf HOME: /home/prueba Shell: /bin/ksh OK? (y/n) [y]: y Added user ``prueba'' Copy files from /etc/skel to /home/prueba Add another user? (y/n) [y]: n Goodbye! Una vez creado el usuario, definimos la reglas que van a regir al mismo, para ello creamos la siguiente estructura. #mkdir /etc/authpf/users #mkdir /etc/authpf/users/prueba #touch /etc/authpf/users/prueba/authpf.rules 3. Solución 7/11

En el archivo /etc/authpf/users/prueba/authpf.rules definimos las reglas de la siguiente manera. #Hacemos referencia a las interfaces lan="rl0" ap="rl1" externa="sis0" #Especificamos lo puertos que se van a permitir. puertos_permitidos="{ftp, ftp-data, ssh, http, https}" mi_red="192.168.1.0/24" # De esta forma se el concede libertad absoluta a esta ip pass in quick on $ap from $user_ip to any 4. Pruebas 4.1 Concepto La idea es realizar una prueba con un usuario no autenticado en el sistema para ver el nivel de privilegios que este maneja en la red, lo mismo se realiza con un usuario autenticado para visualizar la diferencia en el nivel de privilegios de cada uno de los usuarios. 4.2 Probando con un usuario no autenticado. La primera prueba consiste en realizar un ping abierto donde se hace uso de un usuario no autenticado para verificar si se alcanza todos los segmentos de la red LAN. # ping 192.168.50.1 PING 192.168.50.1 (192.168.50.1) 56(84) bytes of data. Como podemos observar no hay respuesta a la solicitud ICMP lo cual nos indica que la maquina no puede alcanzar los otros segmentos de la red, este es el resultado esperado. Solo para estar seguro realizamos una segunda prueba, pero esta vez usando NMAP a una maquina en otro segmento de red. # nmap -sv 192.168.40.0/24 Starting Nmap 5.00 ( http://nmap.org ) at 2010-06-09 15:49 COT 4. Pruebas 8/11

Nmap done: 256 IP addresses (0 hosts up) scanned in 206.32 seconds Se puede evidenciar que NMAP no ha podido escanear la maquina, lo que nos permite concluir que este usuario solo puede ver los equipos en su mismo segmento de red. 4.3 Probando con un usuario autenticado. Como el encabezado lo menciona nos autenticamos por medio de SSH, una vez autenticados el usuario puede ver todos lo segmentos de la red LAN y al mismo tiempo conectarse a los mismos, cabe aclarar que una vez logueado el usuario la ventana queda inactiva y debera conectarse a la red por medio de otra consola; la sesión termina cuando el usuario cierra la terminal o se desvincula de la conexión por medio del comando exit. # ssh prueba@192.168.50.1 prueba@192.168.50.1's password: Last login: Tue Jun 8 11:02:30 2010 from 192.168.50.151 Hello anderson. You are authenticated from host "192.168.50.151" De esta manera garantizamos el acceso a toda la red LAN, una zona que es totalmente restringida a un usuario que no ha sido autenticado usando AuthPF. Este esquema funciona a modo de portal cautivo, pero validandonos con SSH contra el gateway principal de la red. Para verificarlo basta con hacer ping a cualquier equipo de la red LAN ~$ ping 192.168.40.1 PING 192.168.40.1 (192.168.1.40.1) 56(84) bytes of data. 64 bytes from 192.168.40.1: icmp_seq=1 ttl=63 time=3.20 ms 64 bytes from 192.168.40.1: icmp_seq=2 ttl=63 time=0.385 ms 64 bytes from 192.168.40.1: icmp_seq=3 ttl=63 time=0.386 ms 64 bytes from 192.168.40.1: icmp_seq=4 ttl=63 time=0.407 ms 64 bytes from 192.168.40.1: icmp_seq=5 ttl=63 time=0.394 ms o hacer uso de NMAP 4. Pruebas 9/11

$ nmap -sv 192.168.40.16 Starting Nmap 5.00 ( http://nmap.org ) at 2010-06-09 17:07 COT Interesting ports on 192.168.40.16: Not shown: 994 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp VsFTPD 1.5 22/tcp open ssh OpenSSH 5.1p1 Arch Linux (protocol 2.0) 53/tcp open domain ISC BIND 9.5.1-P3 80/tcp open http Apache 2.0 httpd 111/tcp open rpcbind 443/tcp open ssl/http Apache httpd Service Info: OSs: Unix, Linux 5. Conclusiones A modo personal consideramos que esta es una solucion bastante útil y se prodia decir que muy economica para segmentar una red y añadirle seguridad. Con este corto manual nos damos cuenta del poder del Packet filter y de los componentes instalados en la base del sistema OpenBSD, con el diagrama adecuado y unos sencillos pasos, podemos convertir un computador de pocas prestaciones en un excelente firewall y autenticador de acceso a la red. Este esquema se puede considerar un portal cautivo con validación a través de ssh, cuando los usuarios se autentican o terminan la sesión se genera un log en el archivo /var/log/messages que puede usarse para hacer control de tiempo, este esquema funcionaría si es necesario llevar procesos de accounting en la red. Es viable escalar esta solución para configurar cualquier escenario que necesitemos, pues lo único que varían son las reglas personalizadas de usuarios que van en los archivos authpf.rules en las rutas: /etc/authpf/users/usuario/authpf.rules. Teniendo esta herramienta configurada solo tendremos que planear que es lo que queremos hacer, que queremos permitir y que queremos restringir en nuestro entorno y AuthPF hará el trabajo por nosotros. 6. Enlaces relacionados 6. Enlaces relacionados 10/11

http://www.openbsdcolombia.org/ http://www.openbsd.org/faq/pf/authpf.html http://openbsd.org/faq/pf/ http://openbsd.org/faq/pf/macros.html http://openbsd.org/faq/pf/nat.html http://openbsd.org/faq/pf/anchors.html 6. Enlaces relacionados 11/11