=-[ 0x07 ]-================================================================== 
=-[ NetSearch Ezine #8 ]-==================================================== 
=-[ Instalaci?e OpenBSD e Iniciacion a Packet Filter ]-=================== 
=-[ por Pantarhei ]-========================================================= 
 
 
 
 
Instalaci?el sistema operativo 
--------------------------------- 
 
Arrancaremos la instalaci?esde el CD-ROM, para ello insertamos el CD de 
OpenBSD y cambiamos en la BIOS la opci?ara 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?odr?os hacer cosas como configurar ciertas partes del kernel 
sin tener que recompilarlo, cargar un kernel alternativo, arrancar en modo 
monousuario, y muchas m?cosas, pero de momento le daremos a la tecla 
"Enter" o dejaremos pasar unos segundos que con eso ya nos vale para la 
instalaci?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. Despu?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 disposici? 
Con 'p' se nos muestran todos los slices ya existentes, de los cuales siempre 
existir?c' que simboliza el tama?el disco y no ocupa nada de espacio. La 
tecla 'a' nos sirve para a?r slices, as?ue a?mos las que nos hagan 
falta. El slice 'a' se usa normalmente para la partici?a? y la 'b' para 
la swap.  
 
Es importante resaltar que tenemos dos maneras para indicar el tama?e los 
slices, en megabytes y en sectores. A?remos siempre primero la swap parWa 
que quede primero en la geometr?del disco por si nos da por aumentar el 
tama?e nuestras dem?slices. El offset siempre dejamos el que sale por 
defecto, y el tama?n megas lo damos a?endo 'M' al final (400M p.ej). Si 
quisi?mos a?rlo en sectores pues ser?como si di?mos el tama?n 
kilobytes y ser?algo as?omo el doble de lo que queramos a?r en megas 
(si queremos tener una swap de 200 megas y damos el tama?n sectores, 
ser? unos 800000 sectores, que saldr? 395 MB m?o menos).  
 
Ya s?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?ue tecleamos 'done', y formatear?os slices con el 
sistema de ficheros antes indicado. Nos dar?a posibilidad de a?r slices 
en otro disco, pero como no queremos pues seguimos.  
 
Lo siguiente ser?a configuraci?e la red. Pondremos los valores seg?
nuestra red. S?indicar que existen varios drivers seg?a tarjeta de red 
que usemos, as?ue 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 llamar?eth*), etc. Tras esto nos dara la 
posibilidad de escapar a la shell, pero seguimos adelante, e introduciremos 
la contrase?e root en el siguiente prompt. 
 
Lo ?mo ser?e donde queremos instalar los paquetes. Si tenemos una 
conexi?al que una adsl (de cualquier tipo) es una buena opci?nstalar 
via ftp/http, ya que tarda como mucho 1 hora m?o menos todo el sistema.  
Nosotros como ahora mismo no tenemos conexi? 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 m?mo.  
 
 
Cortafuegos en OpenBSD 
---------------------- 
 
PF son las siglas de Packet Filter que sustituy? anterior firewall que 
llevaba de serie OpenBSD, el IPF. Este ten?una licencia tal que s?
permit?a su creador, Darren Reed, hacer modificaciones sobre el c?o, as?
que cada d?recib?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 pod? usar reglas bidireccionales 
en un bridge, la s?axis de las reglas se pod?mejorar, el c?o de la 
zona de usuario era muy fr?l, etc. Finalmente se cansaron de que Darren no 
aceptara todas las modificaciones que los desarrolladores le ofrec? 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 ?ol de ports.  
 
PF se cre?tonces con la misma idea que IPF, pero con las modificaciones 
que los desarrolladores quer? hacerle, as?mejor? sintaxis pudi?ose 
agrupar las reglas en listas, tipo "... from {172.26.0.0/16, 192.168.1.0/24 } 
...", lo que en IPF vendr?a dividirse en dos reglas. Se a??a nueva 
directiva llamada "scrub", que permit?"normalizar" paquetes IP, esto se 
refiere a que con esta directiva, por ejemplo, si una determinada cantidad de 
paquetes que se dirige a nuestra m?ina van fragmentados, y ello no era 
necesario en el env? esta directiva en vez de pasar fragmento a fragmento a 
la pila tcpip para que all?e reensamblen los reensambla en el firewall, 
para que pasen como un solo paquete. Esto lo hacen algunos programas para 
poder pasar ciertos datos a trav?de firewalls o para evadir IDS como Snort. 
 
Se a? una tabla de estado para sesiones TCP que m?adelante se comentar?
soporta ipv6, incorpora un sistema f?l para sistemas con IP din?ca. Se 
pueden filtrar los t?cos protocolos TCP, UDP, ICMP, y se incorpora el 
protocolo ESP. El firewall tambi?permite hacer NAT.  Actualmente se est?
trabajando en una nueva directiva "antispoof" y se est?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?omo las de 
nateado y normalizaci?e paquetes, pero hemos de guardar un orden en dicho 
fichero para las reglas: primero podemos colocar ciertas opciones, luego ir?
las de normalizaci?nateado, y filtrado. El fichero con los filtros lo 
cargaremos en el kernel con una utilidad llamada pfctl que comentar?ras 
explicar las directivas. Existen otro tipo de aplicaciones para PF que 
trabajan con ?a trav?de un interfaz que se nos proporciona a trav?de 
ioctl.  
 
El funcionamiento de un firewall es analizar cada paquete que pasa por ?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 ?ma 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 m?general a lo m?espec?co. 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 t?co 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 tambi?se aplica al 
tr?co entrante, por lo tanto, como no hay mas reglas, se aplica la ?ma 
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 desear?os en nuestro firewall, as?ue existe una directiva que cambia 
este comportamiento de "la ?ma 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 m?sencilla la 
lectura de las reglas. La directiva importante aqu?s "quick". Como veis se 
permite el uso de variables para una mejor lectura. La segunda regla como 
podreis ver es f?l de entender: pasa el tr?co 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 ?ma regla coincidente, por lo 
tanto lee la primera regla que bloquea todo el tr?co entrante, no sigue 
leyendo del fichero, y descarta el paquete.  
 
Una vez visto el funcionamiento vamos a ir introduciendo m?directivas en 
base a las que filtrar. 
 
 webserver="172.26.0.5/32" 
 intranet="172.26.0.0/24" 
 un_ports="1025 >< 65535" # as?ndicaremos 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 tr?co 
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 
tr?co entrante no cumple estos requisitos pasar? la siguiente regla, que 
bloquea todo el tr?co entrante. Los comentarios van tras el s?olo #.  
B?camente este es el funcionamiento m?simple. Para referirnos al tr?co 
saliente cambiar?os la palabra "in" por "out". No es necesario especificar 
tanto par?tro como puerto origen, protocolo y dem?como podreis imaginar.  
 
Es tambi?posible filtrar en base a las "banderas" (de aqu?n 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?ndicaremos 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 par?tros, eso va a vuestro gusto. S?
pasar?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 s?queremos que evalue las flags 
indicadas en Y, y de dicho conjunto, que s?las que est?en X est?
activadas. En definitiva, ser?como decir que queremos que las de X est?
activadas (= 1) y las de Y desactivadas (= 0). Podemos indicar s?el primer 
conjunto o s?el segundo tal que quede "flags S" (el segundo conjunto por 
defecto ser? las dem?flags) o "flags /S" (el primer conjunto ser? las 
dem?flags).  
 
Tenemos una opci?uy 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 ser?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 conexi?As?podremos poner una regla que pase s?el SYN de 
principio de conexi?y una vez que esta regla coincide, se crea una entrada 
para esa conexi?n una "tabla de estado" y autom?camente deja pasar todos 
los paquetes de esa comunicaci?As?ismo, se borra dicha entrada de la 
tabla de estado cuando se cierra la conexi? cuando se agota el tiempo de 
espera (timeout), que podemos configurarlo nosotros mismos en el cortafuegos 
con una opci?timeout" y tambi?el n?o m?mo 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 n?o de secuencia 
(ISN) del paquete con el de la tabla de estado, y as?abe 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 p?na man de pf, y es 
que si tenemos una tabla de estado con 50.000 entradas s?se necesitan 16 
comparaciones para saber si pertenece o no a algun estado; en caso de que no, 
pasar?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 s?ciertos 
paquetes o todos los paquetes que pasan por una comunicaci?on 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??los paquetes que pasen por el interfaz rl0, protocolo tcp con 
direcci?estino nuestro servidor FTP, puerto destino 21 y con el flag SYN 
activado. Si en vez de "log" ponemos "log-all" logear?oda la comunicaci?
(s?con "keep state" o "modulate state"). Todo se logea al interfaz pflog0 
y en formato pcap de tcpdump, as?ue para visualizar el tr?co hacemos 
"tcpdump -i pflog0"  (no os preocupeis por el mensaje que os dar?l 
principio), Si arrancamos el demonio "pflogd" escribir?l tr?co al 
/var/log/pflog . 
 
Con "keep state" hemos conseguido evitar que un usuario malicioso spoofee su 
direcci? intervenga en la comunicaci?basando la seguridad de la misma 
en el ISN. Como bien sabemos existen pilas y pilas, unas con un procedimiento 
de generaci?e ISN's m?d?les a la hora de romperlas y otras m?
fuertes. Para reforzar la seguridad en este punto en sistemas operativos que 
generen ISN's d?les se a? la opci?modulate state", que en base a los 
ISN's genera otros de m?"calidad", con lo que cubrimos otro importante 
aspecto de la seguridad. Esta caracter?ica lleva impl?to el uso de "keep 
state" y s?se aplica a conexiones TCP l?amente. As?os quedar? 
 
pass in log-all on rl0 proto tcp from any to $ftpserver port = 21 flags 
S/SA modulate state 
 
Otra caracter?ica es la que se define como una "normalizaci?e 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 prevenci?e ataques de 
fragmentaci?e paquetes IP para poder pasar ciertos paquetes a trav?de un 
cortafuegos. Adem?de esto, podemos cambiar el bit DF (Don't Fragment), el 
TTL (Time To Live) m?mo (paquetes IP) y el MSS (Maximun Segment Size)  
m?mo (paquetes TCP).  
 
Algo que pod?os echar de menos de IPFilter es la posibilidad de agrupar 
reglas, por ejemplo seg?l interfaz, de manera que pod?os agrupar una 
serie de reglas que pertenecieran al interfaz rl0, entonces, si un paquete va 
al interfaz rl1 al cortafuegos le bastar?con mirar la primera regla del 
grupo de reglas de rl0 para saber que ya no tiene que leer m?reglas de ese 
grupo. Pero Packet Filter tambi?cubre ese aspecto, y lo hace 
autom?camente, 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?a primera regla de 
este grupo de 4, y como van dirigidas a los paquetes que vayan al interfaz 
rl0, pasar?as 3 siguientes. Esta caracter?ica s?funciona cuando las 
reglas son consecutivas, por ello hemos de tener ordenadas nuestras reglas 
seg?ste orden: 
 
1. Por interfaz 
2. Por protocolo 
3. Por direcci?e origen 
4. Por puerto de origen 
5. Por direcci?e destino 
6. Por puerto de destino 
 
As?ue ordenaremos las reglas primero por interfaz, despu? dentro del 
grupo del interfaz por protocolo, etc.  
 
Espero terminar dentro de poco el art?lo documentando un poco m?el Packet 
Filter. 
 
Sugerencias, comentarios:  
 
pantarhei@funfatal.org o pantarhei@2500hz.net 
 
 
Pantarhei 
 
 
 
0x00