Está en la página 1de 6

=-[ 0x07 ]-==================================================================

=-[ NetSearch Ezine #8 ]-====================================================


=-[ Instalacin de OpenBSD e Iniciacion a Packet Filter ]-===================
=-[ por Pantarhei ]-=========================================================

Instalacin del sistema operativo


---------------------------------
Arrancaremos la instalacin desde el CD-ROM, para ello insertamos el CD de
OpenBSD y cambiamos en la BIOS la opcin para que arranque desde el CD-ROM.
Una vez hecho esto y al arrancar nos encontramos con que se nos presenta un
prompt:
boot>
Desde aqu podramos hacer cosas como configurar ciertas partes del kernel
sin tener que recompilarlo, cargar un kernel alternativo, arrancar en modo
monousuario, y muchas ms cosas, pero de momento le daremos a la tecla
"Enter" o dejaremos pasar unos segundos que con eso ya nos vale para la
instalacin. Se carga el kernel en memoria y comienza a reconocer nuestros
dispositivos... Lo siguiente:
(I)nstall, (U)pgrade or (S)hell?
Pulsamos 'I'.
Specify terminal type [vt100]:
Escogemos el tipo de terminal que queramos. Despus nos pregunta si queremos
usar todo el disco para OpenBSD, pues s. Se nos presenta otro prompt, desde
el que configuraremos los slices ("particiones") de nuestra OpenBSD. Si
tecleamos '?' veremos todos los comandos que tenemos a nuestra disposicin.
Con 'p' se nos muestran todos los slices ya existentes, de los cuales siempre
existir 'c' que simboliza el tamao del disco y no ocupa nada de espacio. La
tecla 'a' nos sirve para aadir slices, as que aadimos las que nos hagan
falta. El slice 'a' se usa normalmente para la particin raz, y la 'b' para
la swap.
Es importante resaltar que tenemos dos maneras para indicar el tamao de los
slices, en megabytes y en sectores. Aadiremos siempre primero la swap parWa
que quede primero en la geometra del disco por si nos da por aumentar el
tamao de nuestras dems slices. El offset siempre dejamos el que sale por
defecto, y el tamao en megas lo damos aadiendo 'M' al final (400M p.ej). Si
quisiramos aadirlo en sectores pues sera como si diramos el tamao en
kilobytes y sera algo as como el doble de lo que queramos aadir en megas
(si queremos tener una swap de 200 megas y damos el tamao en sectores,
seran unos 800000 sectores, que saldran 395 MB ms o menos).
Ya slo nos queda indicar el tipo de sistema de ficheros 4.4BSD y el punto de
montaje, para la swap ninguno. 'w' para guardar la tabla de particiones y 'q'
para salir. En la siguiente pantalla podemos indicar los puntos de montaje
pero ya los pusimos, as que tecleamos 'done', y formatear los slices con el
sistema de ficheros antes indicado. Nos dar la posibilidad de aadir slices
en otro disco, pero como no queremos pues seguimos.
Lo siguiente ser la configuracin de la red. Pondremos los valores segn
nuestra red. Slo indicar que existen varios drivers segn la tarjeta de red
que usemos, as que el nombre del interfaz de red ethernet se llamar, si
usamos una Realtek rl0, si usamos una Intel fxp0, ne0 para realtek's
antiguas, (en linux siempre se llamara eth*), etc. Tras esto nos dara la
posibilidad de escapar a la shell, pero seguimos adelante, e introduciremos
la contrasea de root en el siguiente prompt.
Lo ltimo ser de donde queremos instalar los paquetes. Si tenemos una
conexin tal que una adsl (de cualquier tipo) es una buena opcin instalar
via ftp/http, ya que tarda como mucho 1 hora ms o menos todo el sistema.
Nosotros como ahora mismo no tenemos conexin a internet lo hacemos desde
CD-ROM y seleccionando los paquetes a instalar. Los que ya vienen por defecto
son necesarios para que funcione el sistema con lo mnimo.

Cortafuegos en OpenBSD
----------------------
PF son las siglas de Packet Filter que sustituy al anterior firewall que
llevaba de serie OpenBSD, el IPF. Este tena una licencia tal que slo
permita a su creador, Darren Reed, hacer modificaciones sobre el cdigo, as
que cada da reciba varios mails de desarrolladores OpenBSD ofreciendo
soluciones a partes de su firewall mal codeadas o de bajo rendimiento.
Algunas cosas que citaba Theo de Raadt en una entrevista publicada en
kerneltrap.org fueron por ejemplo el pobre tratamiento de los mbufs para ipv6
(skb's en Linux, buffers de inet), no se podan usar reglas bidireccionales
en un bridge, la sntaxis de las reglas se poda mejorar, el cdigo de la
zona de usuario era muy frgil, etc. Finalmente se cansaron de que Darren no
aceptara todas las modificaciones que los desarrolladores le ofrecan y
decidieron quitarlo del sistema a partir de la release 3.0. A partir de este
problema de licencia se removieron otros muchos paquetes del rbol de ports.
PF se cre entonces con la misma idea que IPF, pero con las modificaciones
que los desarrolladores queran hacerle, as, mejor la sintaxis pudindose
agrupar las reglas en listas, tipo "... from {172.26.0.0/16, 192.168.1.0/24 }
...", lo que en IPF vendra a dividirse en dos reglas. Se aadi una nueva
directiva llamada "scrub", que permita "normalizar" paquetes IP, esto se
refiere a que con esta directiva, por ejemplo, si una determinada cantidad de
paquetes que se dirige a nuestra mquina van fragmentados, y ello no era
necesario en el envo, esta directiva en vez de pasar fragmento a fragmento a
la pila tcpip para que all se reensamblen los reensambla en el firewall,
para que pasen como un solo paquete. Esto lo hacen algunos programas para
poder pasar ciertos datos a travs de firewalls o para evadir IDS como Snort.
Se aade una tabla de estado para sesiones TCP que ms adelante se comentar,
soporta ipv6, incorpora un sistema fcil para sistemas con IP dinmica. Se
pueden filtrar los tpicos protocolos TCP, UDP, ICMP, y se incorpora el
protocolo ESP. El firewall tambin permite hacer NAT. Actualmente se est
trabajando en una nueva directiva "antispoof" y se estn haciendo mejoras en
su rendimiento y corrigiendo algunos fallos, que siempre los hay.
PF usa entonces un fichero del que lee las reglas de filtrado as como las de
nateado y normalizacin de paquetes, pero hemos de guardar un orden en dicho
fichero para las reglas: primero podemos colocar ciertas opciones, luego irn
las de normalizacin, nateado, y filtrado. El fichero con los filtros lo
cargaremos en el kernel con una utilidad llamada pfctl que comentar tras
explicar las directivas. Existen otro tipo de aplicaciones para PF que
trabajan con l a travs de un interfaz que se nos proporciona a travs de
ioctl.
El funcionamiento de un firewall es analizar cada paquete que pasa por l y
en base a las reglas decide que hacer con el paquete. PF no decide que hacer
con el paquete cuando coincide con una regla, sino que sigue analizando las
reglas, y la ltima que coincida es la que se lleva a cabo. Si ninguna regla
coincide con el paquete, por defecto se decide pasarlo. Por lo tanto
deberemos seguir a la hora de hacer nuestro fichero de reglas un filtrado de
lo ms general a lo ms especfico. Para cada paquete que coincide con una
regla se puede pasar con la directiva "pass" o bloquear con "block".
Para explicar el funcionamiento a la hora de parsear el fichero lo mejor ser
ver el tpico ejemplo:
block in all
pass in all
La primera regla se aplica a todo paquete entrante, pero como dije antes PF
no se para ah, sino sigue leyendo. La siguiente regla tambin se aplica al
trfico entrante, por lo tanto, como no hay mas reglas, se aplica la ltima
que coincide con el paquete, en este caso es nuestra regla "pass in all", por
lo tanto el paquete se pasa a la pila. A veces no es este el funcionamiento
que desearamos en nuestro firewall, as que existe una directiva que cambia
este comportamiento de "la ltima regla coincidente decide que hacer":
webserver="172.26.0.5/32"
block in quick all
pass in from any to $webserver
Como veis se nos permite el uso de variables para hacer ms sencilla la
lectura de las reglas. La directiva importante aqu es "quick". Como veis se
permite el uso de variables para una mejor lectura. La segunda regla como
podreis ver es fcil de entender: pasa el trfico entrante que venga desde
una ip cualquiera (any) al servidor web, pero esta regla nunca llega a
cumplirse. La directiva "quick" aplicada a una regla cambia el comportamiento
del firewall haciendo que esa sea nuestra ltima regla coincidente, por lo
tanto lee la primera regla que bloquea todo el trfico entrante, no sigue
leyendo del fichero, y descarta el paquete.
Una vez visto el funcionamiento vamos a ir introduciendo ms directivas en
base a las que filtrar.
webserver="172.26.0.5/32"
intranet="172.26.0.0/24"
un_ports="1025 >< 65535" # as indicaremos los rangos de puertos
pass in quick on rl0 proto tcp from $intranet port $un_ports to
$webserver port = 80
block in quick all
Leamos las reglas para aclarar las nuevas directivas: dejo pasar trfico
entrante tcp que proviene del interfaz rl0 (nombre de interfaz cuando el
chipset es realtek), con ip origen 172.26.0.0/24 y puerto origen cualquiera
entre 1025 y 65535, con ip destino 172.26.0.5 y puerto destino el 80. Si el
trfico entrante no cumple estos requisitos pasar a la siguiente regla, que
bloquea todo el trfico entrante. Los comentarios van tras el smbolo #.
Bsicamente este es el funcionamiento ms simple. Para referirnos al trfico
saliente cambiaramos la palabra "in" por "out". No es necesario especificar
tanto parmetro como puerto origen, protocolo y dems como podreis imaginar.
Es tambin posible filtrar en base a las "banderas" (de aqu en adelante
"flags") de los paquetes TCP: SYN, ACK, RST, PUSH, FIN, URG, CWR, ECE. Nos
referiremos a ellas por su inicial, salvo en el caso de CWR, que lo haremos
con la W:
webserver="172.26.0.5/32"
intranet="172.26.0.0/24"
un_ports="1025 >< 65535" # as indicaremos los rangos de puertos
# o para rangos excluyentes: 1025<>65535
block in all
pass in on rl0 proto tcp from $intranet to $webserver port = 80
flags S/SA
Vereis que he eliminado ciertos parmetros, eso va a vuestro gusto. Slo
pasarn los paquetes tcp que vengan del interfaz rl0 desde una ip de la
intranet a nuestro servidor web en el puerto 80 y que contenga, del conjunto
de flags que forman el SA (SYN, ACK), el bit SYN activado. As, si tenemos
"flags X/Y", estamos indicando que slo queremos que evalue las flags
indicadas en Y, y de dicho conjunto, que slo las que estn en X estn
activadas. En definitiva, sera como decir que queremos que las de X estn
activadas (= 1) y las de Y desactivadas (= 0). Podemos indicar slo el primer
conjunto o slo el segundo tal que quede "flags S" (el segundo conjunto por
defecto seran las dems flags) o "flags /S" (el primer conjunto seran las
dems flags).
Tenemos una opcin muy interesante llamada "keep state":
ftpserver="172.26.0.5/32"
block in all
pass in on rl0 proto tcp from any to $ftpserver port = 21
flags S/SA keep state
Lo normal sera que si usamos un cortafuegos delante de un servidor ftp, el
servidor ftp lo tengamos en modo pasivo, para saber que puertos abre para la
transferencia de ficheros y dejarlos abiertos en el cortafuegos. Para evitar
esto tenemos "keep state". Hace exactamente lo que dice, "guardar el estado"
de la conexin. As, podremos poner una regla que pase slo el SYN de
principio de conexin, y una vez que esta regla coincide, se crea una entrada
para esa conexin en una "tabla de estado" y automticamente deja pasar todos
los paquetes de esa comunicacin. As mismo, se borra dicha entrada de la
tabla de estado cuando se cierra la conexin o cuando se agota el tiempo de
espera (timeout), que podemos configurarlo nosotros mismos en el cortafuegos
con una opcin "timeout" y tambin el nmero mximo de entradas en la tabla
de estado para dicha regla con "max".
Cuando existen entradas en dicha tabla de estado y un paquete entra a nuestro
cortafuegos, este lo primero que hace es comprobar el nmero de secuencia
(ISN) del paquete con el de la tabla de estado, y as sabe si el paquete
pertenece o no a la entrada de la tabla. Con esto evitamos spoofing de
direcciones. Tiene otra ventaja tal y como dice en la pgina man de pf, y es
que si tenemos una tabla de estado con 50.000 entradas slo se necesitan 16
comparaciones para saber si pertenece o no a algun estado; en caso de que no,
pasara a ser visto por las reglas de filtrado siguientes. Un ejemplo con
las opciones de keep state:
ftpserver="172.26.0.5/32"
pass in proto tcp from any to $ftpserver port 21 flags S/SA keep state (max
100)
Algo importante que destacar es la posibilidad de logear slo ciertos
paquetes o todos los paquetes que pasan por una comunicacin con keep state.
Si tenemos la regla anterior:
pass in log on rl0 proto tcp from any to $ftpserver port = 21
^^^
flags S/SA keep state
logear slo los paquetes que pasen por el interfaz rl0, protocolo tcp con
direccin destino nuestro servidor FTP, puerto destino 21 y con el flag SYN
activado. Si en vez de "log" ponemos "log-all" logear toda la comunicacin
(slo con "keep state" o "modulate state"). Todo se logea al interfaz pflog0
y en formato pcap de tcpdump, as que para visualizar el trfico hacemos
"tcpdump -i pflog0" (no os preocupeis por el mensaje que os dar al
principio), Si arrancamos el demonio "pflogd" escribir el trfico al
/var/log/pflog .
Con "keep state" hemos conseguido evitar que un usuario malicioso spoofee su
direccin e intervenga en la comunicacin, basando la seguridad de la misma
en el ISN. Como bien sabemos existen pilas y pilas, unas con un procedimiento
de generacin de ISN's ms dbiles a la hora de romperlas y otras ms
fuertes. Para reforzar la seguridad en este punto en sistemas operativos que
generen ISN's dbiles se aade la opcin "modulate state", que en base a los
ISN's genera otros de ms "calidad", con lo que cubrimos otro importante
aspecto de la seguridad. Esta caracterstica lleva implcito el uso de "keep
state" y slo se aplica a conexiones TCP lgicamente. As nos quedara:
pass in log-all on rl0 proto tcp from any to $ftpserver port = 21 flags
S/SA modulate state
Otra caracterstica es la que se define como una "normalizacin de paquetes".
Se aplica con la directiva "scrub" y consiste en reensamblar los fragmentos
IP de un paquete antes de pasar por las reglas del cortafuegos. Esto cubre
otro aspecto importante de seguridad que es la prevencin de ataques de
fragmentacin de paquetes IP para poder pasar ciertos paquetes a travs de un
cortafuegos. Adems de esto, podemos cambiar el bit DF (Don't Fragment), el
TTL (Time To Live) mnimo (paquetes IP) y el MSS (Maximun Segment Size)
mximo (paquetes TCP).
Algo que podamos echar de menos de IPFilter es la posibilidad de agrupar
reglas, por ejemplo segn el interfaz, de manera que podamos agrupar una
serie de reglas que pertenecieran al interfaz rl0, entonces, si un paquete va
al interfaz rl1 al cortafuegos le bastara con mirar la primera regla del
grupo de reglas de rl0 para saber que ya no tiene que leer ms reglas de ese
grupo. Pero Packet Filter tambin cubre ese aspecto, y lo hace
automticamente, sin directivas. Si por ejemplo tenemos una serie de reglas:

block in quick on rl0 from 10.0.0.0/8 to any


block in quick on rl0 from 172.16.0.0/12 to any
block in quick on rl0 from 192.168.0.0/16 to any
block in quick on rl0 from 255.255.255.255/32 to any

Si un paquete se recibe por el interfaz rl1, PF mirar la primera regla de


este grupo de 4, y como van dirigidas a los paquetes que vayan al interfaz
rl0, pasar las 3 siguientes. Esta caracterstica slo funciona cuando las
reglas son consecutivas, por ello hemos de tener ordenadas nuestras reglas
segn este orden:
1. Por interfaz
2. Por protocolo
3. Por direccin de origen
4. Por puerto de origen
5. Por direccin de destino
6. Por puerto de destino
As que ordenaremos las reglas primero por interfaz, despus, dentro del
grupo del interfaz por protocolo, etc.
Espero terminar dentro de poco el artculo documentando un poco ms el Packet
Filter.
Sugerencias, comentarios:
pantarhei@funfatal.org o pantarhei@2500hz.net

Pantarhei

0x00