Casodestudio authpf

Caso de estudio: AuthPF - Waldo, Anderson, http://www.openbsdcolombia.org/

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

Fig 1. Topología de Ejemplo

2.2. Definiendo las reglas

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


status: active
inet6 fe80::2c0:a8ff:fe7a:f5c1%rl0 prefixlen 64 scopeid 0x2
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:08:a1:85:de:c4
priority: 0
status: active
inet6 fe80::208:a1ff:fe85:dec4%rl1 prefixlen 64 scopeid 0x3

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

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

Casodestudio authpf

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to Casodestudio authpf

Similar to Casodestudio authpf (20)

Recently uploaded

Recently uploaded (20)

Casodestudio authpf