Iepe a todos! Abe, tengo unas cuantas dudas sobre teoria de firewalls de las que la literatura clasica del tema no me aclara, puesto que algunos tiran por un lau, otros por otro, y otros simplemente no hablan de ello, y quisiera saber la opinion de la gente al respecto.
Pa empezar, y como aclaracion, soy de los que piensan que un buen firewall
deberia de cortar todo el trafico ( tanto in como out) menos el
explicitamente autorizado. En esto creo que casi todos taremos de acuerdo :P
Y bueno, las dudas llegan ahora:
- Que tratamiento deberia de tener la iface local (lo0)? Mucha
documentacion
pasa olimpicamente de ella, y me parece un tema interesante. el Packet Filter
Guide de OpenBSD recomienda desactivar el filtro en esa iface, y otros muchos
abren asaco. Otros en cambio, meten filtros explicitos para aceptar
unicamente los servicios usados, y siempre con src y dst 127.0.0.1. Yo la
verdad, no me decido. Por un lado el no tratar dicha iface nos quita bastante
trabajo del firewall en caso de tener servicios internos que se comuniquen
por lo0 (amavisd y postfix por ejemplo), pero por otro me parece mas correcto
aceptar solo el trafico necesario, de forma que tendremos mayor seguridad en
el sistema en caso de compromiso (siguiendo con el ejemplo de antes, se le
permite unicamente a postfix comunicarse con amavisd).
- En un router con pequeños servicios (dns y tal, en un router/firewall
casero por ejemplo), como se deberian de tratar las peticiones locales a
ifaces externas? Pongo un ejemplo que no me parece que se entienda muy bien:
Por ejemplo, acceso al server dns local via la ip de eth0. En este toy
bastante decidido, aunque si alguien se anima a dar su opinion, me gustaria
oirlo: Las peticiones locales a servicios locales deben de ir via socket
unix/local iface, por lo que dropeo las peticiones en las ifaces de lan/vpn
etc que provengan desde la maquina local (la ip de ese mismo iface), y
configuro el sys para que use los servicios desde 127.0.0.1. No se si le veis
algun tipo de problema a esta conf. Segun como te montau el server dns por
ejemplo sera mas o menos complicado el enlazar todo i tal, pero yo no veo
problema alguno.
- Esta es un poco mas concreta: Supongamos que tenemos un web-proxy por
ejemplo, que hace de web-cache y NAT para una red. Por ahora dejamos
transparent caching y tal a un lado, y suponed que queremos denegar toda
peticion al exterior a los puertos 80/443 ... que no se haga via cache. La
solucion seria autorizar unicamente al servicio de cache mientras dejamos
todas las demas peticiones denegadas. Bien, como seria mejor autorizar al
cache? Por uid y tal (iptables soporta filtrado por users, creo que PF de
openBSD tmb, aunque no toi seguro) o via puertos, lockeando los src ports del
servidor cache a unos concretos por ejemplo, y autorizando las peticiones web
que tengan esos puertos en el source. Y aqui si que no me decido :D. El
filtrado via uid tiene la ventaja de que solo ese user que en teoria ta
controlado y que no ha sido comprometido puede abrir conexiones, y dado que
en el 99% de los casos el user sera noshell y sin pass y tal, en principio se
controlaria el tema. Pero le veo dos problemas: 1: Si se compromete esa
cuenta en concreto podriamos no darnos cuenta de los querys sin cache puesto
que creemos que ta controlau (en fin, lo que pasa con too al final no?) 2: No
nos sirve en un entorno multi maquina porque los filtrados por uid son pa el
trafico generado en la misma maquina (que yo sepa al menos). Al apaño de los
puertos especificos etc, le veo otro problema: a no ser que en el startup o
asi se ponga el server en ese puerto o algo asi, otro user podria usar dicho
puerto para hacer peticiones por lo que pasaria el filtro. Ademas, puede que
el servidor proxy que usemos no nos permita especificar un rango de puertos
especificos para las peticiones salientes, por lo que no seria viable
implementar este metodo. La tercera opcion, seria permitir todo el trafico
80/443... proveniente del equipo proxy, y denegar a las demas maquinas. En
este caso se podria saltar el webcache desde el mismo servidor, aunque
suponiendo que controlamos el server y tal, es sencillo configurarlo para que
use la cache y realmente no filtrar dicho trafico. (Realmente el firewall no
seria tan especifico como lo pediamos, pero se supone que controlamos el
trabajo en el server (amos, que en principio solo hay sesiones interactivas
pa mantenimiento y tal, y los tenemos configuraus para que no hagan
peticiones directas)
Bueno, peaso de mail potrongo que ma salio. Ya lo siento si os aburre
leerlo :P, pero imho taria bien un poco de debate en este tema, pa conocer
puntos de vista de otros. Eno, ta otra y cuidaos en semana santa.
M, acabo de acordarme, dos dudillas mas, abe si alguien sabe responderlas:
Alguien sabe como funciona (que hace exactamente) y/o donde documentarme sobre
el soporte de squid para Packet Filter? (Se que necesita acceso a /dev/pf
para leer la conf del firewall y tal, pero no se exactamente para que lo usa,
y no encuentro documentacion decente).
Y la otra dudilla: me han pedido la conf de un router que permita unicamente
el trafico de las ips asignadas via dhcp (no quieren IPSEC ni na, solo eso).
He pensau que lo mejor seria denegar todo y autorizar con timer en el lease
time a las ips asignadas por dhcp, de forma que si no hay mas peticiones tras
el lease time (amos, sa apagau el cliente ese) desautorizar otra vez. Alguien
sabe si algun server dhcp tiene alguna opcion para ejecutar algo al asignar
una ip? o tendria que hackear el server? Jeje, si alguien ha hecho algo por
el estilo, taria bien saber como lo ha hecho :D.
Eno, y naa mas por hoy. Pa la proxima, dudas sobre QoS y estrategias a
utilizar (orientado principalmente a administrar correctamente la bw de
adsls/cables), que tmb tengo algunas dudillas con el tema :D
Ah, si algo que quereis comentar depende del sistema del firewall, la maquina
concreta que toy montando ahora es FreeBSD con OpenBSD's Packet Filter,
aunque comentad lo que sea sobre cualquier entorno libre :D, fijo que hay
algun workaround parecido en el resto de sistemas
Pf, demasiau largo el mail pa buena cosa :P
--
Julen
[EMAIL PROTECTED]
pgpFa7k5j9M5A.pgp
Description: PGP signature
_______________________________________________ ITSAS mailing list [email protected] http://list.ehu.es/mailman/listinfo/itsas
