litoral: yo no me comprometo, estoy de exámenes y mañana me levanto a las 7:30, por eso he desaparecido del mapa
Maria Jesus Coma: danit
Maria Jesus Coma: algun voluntario mas ?
litoral: (aparte de que no confio tanto en mi nivel de inglés)
Netlag: y como escribe
litoral: ya irá esto funcionando...
Netlag: el tio es brasileiro, no?
Ricardo Javier Cardenes Medina: Nups
litoral: quien es el que hablará?
litoral: el nick, quiero decir...
Ricardo Javier Cardenes Medina: LaForge
Ricardo Javier Cardenes Medina: Harald Welte
Makross: :)
Ricardo Javier Cardenes Medina: Netlag Amos. El nombre no me sugiere Brasil, precisamente :-)
Netlag: ya ya, yo ke se, igual sus papis son alemanes pero como trabaja pa conectiva y tiene .br.. naa no tiene na ke ver
Ricardo Javier Cardenes Medina: Netlag: Está currando para Conectiva :-)
Netlag: el mundo esta globalizado eso nos venden
Ricardo Javier Cardenes Medina: Rik van Riel también, y es holandés :P
Netlag: ok Ricardo Javier Cardenes Medina:.
viper: LaForge>Y Data?
litoral: HOla amigos esta noches teemos la fortuna de tener con nosotros a Harald Welte
(Laforge). El es uno de los principales desarrolladores (o desarrolladores del nucleo) de el proyecto Netfilter el motor de filtrado y motor de (mangling?) para Linux 2.4, y está siendo patrocinado por COnectiva, una Compañía brasileña basada en Linux LAForge, cuando quieras
Empieza LAForge
Hola a todos
Ricardo Javier Cardenes Medina: gracias por la traducción
Ok, voy a dar una introducción sobre Netfilter / iptables es la nueva infraestructura en el sector de redes de linux 2.4, el cual es usado para el filtrado de paquetes /NAT y (mangling?, que es mangling?) es el sucesor de ipfwadm (2.0) e ipchains (2.2)
litoral: es basicamente un completo rediseño / reescritura, y practicamente no ha sovrevidido dinguna linea de los tiempos del 2.2.x
litoral: estoy diciendo que e suna infraestructura, porque es muy genérico para ser utilizado sólo para firewall netfilter, basicamente consiste en un conjunto de hooks (call-back function entry points, funciones de puntos de entrada?) en el código que maneja la red en el nucleo linux estandar esos hooks, son colocados en ciertos puntos de la capa-3 de los protocolos de red
Netlag: puntos de entrada a funciones call-back funciones ke tratan el tema.. por decirlo de alguna manera
litoral: cualquier módulo del kernel puede ahora (register?) asignarse en cualquiera de esos hooks, y cada vez que un paquete pasa por ese hook, el código de manejo de la red, llamará a ese módulo hablaré con más detalle sobre ello más tarde
Primero otra cuestión: ¿Por qué necesitamos netfilter? ¿no era el código 2.2.c suficientemente bueno?
ipchains no tenía una infreestructura para pasar paqueter al espacio de usuario el realizar un proxy transparente era extremadamente dificil todas las reglas de filtrado de paquetes dependían de las direcciones de los interfaces (tarjetas de red?) masquerading (un caso especial de NAT) se colocaba dentro del código de firewall el código era demasidado complicado y desectructurado y no era modular y si muy extenso eso debería ser razón suficiente para un cambio ;) para dar una definición de los términos "netfilter" es el conjunto de hooks en la pila de red linux "iptables" son las tablas/cadenas de reglas, que son implementadas en lo alto de netfilter
Me gustaría que todo el mundo echara un vistazo al texto de esta charla. en la sección 1.4 hay un diagrama este diagrama muestra los hooks de netfilter en la pila IPv4 2.4.x [amguien preguntó que cuando podría preguntar, haré un pequeño receso de vez en cuando para que la gente pueda preguntar] si miramos el diagrama, los paquetes que llegan de un interface de red entran en este por el lado izquierdo
litoral: Ricardo Javier Cardenes Medina:: "dime cuando, LaForge. Quitaré el "moderado" del canal
litoral: LaForge: los paquetes dejando la máquina a través de in interfaz de red salen por el lado derecho los paquetes dirigidos a la máquina local (localmente originados o paquetes destinadoes) van al fondo o vienen del fondo así que si miramos un paquete que viene a un interfaz y que es redirigido a otra red, tenemos el siguiente camino (path) el paquete llega el paquete contacta con el hook PRE_ROUTING el código de enrutado decide que enrutado realizar el paquete llega al hook FORWARD el paquete llega al hook POST_ROUTING el paquete es enviado al interfaz de red de salida haré un pequeño descanso para las preguntas ahora hay alguna pregunta ahora, sobre el diagrama /hooks / ... ?
litoral: Heimy: si teneis alguna pregunta, hacedla ahora... :-)
litoral: dent: este nuevo código es lo suficientemente flexible para que cada instancia deje hacer parecer a un paquete remoto como local?
litoral: LAforge: dent: no, eso no tiene sentido. no es posible
litoral: LAforge: dent: y podrías esperar con preguntas más genéricas al final de la charla
litoral: det: lo siento ;)
litoral: dent dice que esperará
litoral: Laforge: no hay problema
litoral: Ricardo Javier Cardenes Medina: alguna otra pregunta?
litoral: Ricardo Javier Cardenes Medina: mmh... parece que puedes continuar :-)
Ricardo Javier Cardenes Medina:litoral: Te puedes saltar lo siguiente hasta ->
litoral: ok
Ricardo Javier Cardenes Medina: Para ponerte al día :_)
litoral: la sección 1.4 va sobre como otros paquetes atraviesan los hooks de netfilter, podeis leerlo allí
sección 1.5:
cada módulo asignado a uno de esos módulos, tiene que devolver un valos al nucleo de netfilter
que ocurre a los paquetes después del hook, depende del valor de respuesta
NF_ACCEPT significa que el paquete continua, como si nada hubiese pasado
NF_DROP significa que ese paquete es borrado (por ejemplo, simplemente desaparece y nadie más lo habrá visto)
NF_STOLEN significa que el módulo del kernel ( que está adignado al hook) ha tomado control sobre el paquete, y el paquete no debe continuar a través de la pila de la red
NF_QUEUE significa, que ese hook debería ser llamado otra vez
como apuntamos al principio, las verdaderas tablas ip son implementadas en lo alto (al principio?) de netfilter
iptables asignan a los hooks de netfilter
actualmente tenemos tres tablas diferentes, para tres trabajos diferentes:
filtro - para filtrado tradicional de paquetes
nat - para todo tipo de traducciones de direcciones de red
mangle - cualquier cosa que manipula un paquete pero no es NAT ;)
ahora describiré cada una de esas tablas individualmente, empezando con filter
(sección 1.6)
la tabla de filtro se adhiere a tres de los ganchos de netfilter
LOCAL_IN, FORWARD y LOCAL_OUT
la tabla de filtrado tiene una cadena de reglas adherida a cada uno de esos hooks. Los nombres de las cadenas son INPUT, FORWARD y OUTPUT.
si volveis a mirar el diagrama, concluireis, que cada paquete siempre llegará sólo a uno de esos tres hooks (respectivamente a sus cadenas adheridas)
los paquetes redirigidos a otros interfaces _SOLO_ atraviesan la tabla FORWARD
los paquetes que lleguan desde la red, teniendo como destino el firewall, _SOLO_ atraviesan la cadena INPUT
los paquetes enviados desde procesos locales del firewall _SOLO_ atraviesan la cadena OUTPUT
esto es importante para ver la diferencia desde ipchains, donde un paquete reenviado solia atravesar todas las cadenas
ahora que sabemos que hay cadenas dentro de las tablas que se adhieren a hooks. ¿Cómo usamoes eso?
cada cadena está compuesta de una lista de reglas
esa lista de reglas, es recorrida secuencialmente desde el principio hasta el final para cada paquete que llega a esa cadena
cada regla está compuesta de dos partes:
una o más coincidencias, especifican que paquete se ajusta a esa regla
una coincidencia (no estoy muy seguro de esto último), especifica la acción a ser tomada cuando los patrones coinciden (no se si esto es muy claro, DaniT, corrige por favor)
lo bonito que hay con iptables es: es modular
su modularidad (perdón)
cualquier acción o cualquier objetivo puede ser implementado como un módulo separado
así que cualquiera puede simplemente escribir sus propios patrones de objetivos, sin interferir con el netfilter o el código de iptables, hay un programa de linea de comandos, llamado "iptables"
este programa de linea de comandos, es flexible, y maneja todas las operaciones para todas las tablas
así que como usar esta utilidad de linea de comandos?
así que ¿cómo usar esta utilidad de linea de comandos?
debemos construir comandos(seccion 2.2)
en cada se basa en:
- sobre que tabla queremos operar
- que cadena de esa tabla queremos tratar
- que tipo de operacion(insercion, eliminacion, modificacion..)
-------
- que comparaciones queremos utilizar
- que objetivos queremos aplicar
asi que la sintaxis general seria como:
iptables -t ejemplo
iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp
añadimos una regla a la cadena INPUT (entrada) de la tabla de filtrado
esta regla afecta a los paquetes TCP que tienen como puerto de destino el de smtp (25) y los acepta
bien, que tipo de objetivos/criterios tenemos
objetivos:
ACCEPT (acepta un paquete)
DROP (desecha un paquete)
QUEUE (pone un paquete en cola)
REJECT (devuelve un paquete)
LOG ("loguea" un paquete) almacena un registro de su paso
hay mas reglas aparte de estas, para mas detalles echad un vistazo a la documentacion de la presentacion o a la de netfilter/iptables)
en cuanto a los criterios de coincidencia tenemos los criterios basicos:
-p protocolo (tcp/udp/icmp)
-s direccion ip / mascara de origen
-d direccion ip / mascara de destino
-i interfaz de entrada (eth0 / ppp12 / ..)
-o interfaz de salida
--dport (puerto de destino)
--sport (puerto de origen)
--mac-source Dirección (ethernet) MAC
(aqui tambien hay mas criterios, porfavor, miren la docuentacion si necesitan mas informacion al respecto)
DaniT: continuemos pues con el filtrado fcil de paquetes
la siguiente parte de la presentacion es acerca de NAT
(apartado III de la documentacion)
implementado sobre iptables y otras funciones (segimiento de conexion, hablaremos mas adelante) esta el modulo NAT
el modulo NAT es, nuevamente, una infraestructura muy generica para todos los tipos de NAT (traduccion de direcciones de red)
esta infraestructura generica esta controlada por la tabla de NAT (TDR)
la tabla de NAT enlaza nuevamente a tres de los hooks de netfilter
tenemos la cadena PREROUTING (hook NF_IP_PREROUTING)
POSTROUTING(NF_IP_POSTROUTING) y OUTPUT (NF_IP_LOCAL_OUT).
el tipo de NAT que queremos hacer esta especificado por reglas en esas cadenas, a traves de etiquetas NAT
tenemos basicamente dos categorias de NAT
NAT en origen y NAT en destino
NAT en destino cambia la direccion de origen del paquete
NAT en destion cambia la direccion de destino del paquete
SNAT sucede en el hook POST_ROUTING
DNAT en el hook PRE_ROUTING
por que?
por que si cambias esa diceccion de destino, debes hacerlo antes de la decision de enrutado
(que esta basada en la direccion de destino)
MASQUERADE es un caso especial de SNAT
REDIRECT es un caso especial de DNAT
ejemplos
iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -s 10.0.0.0/8
añadimos una regla a la cadena POSTROUTING en la tabla NAT
la regla dice: SNAT todos los paquetes cuya direccion de origen este 10.0.0.0/8 a la nueva direccion 1.2.3.4
esta es una regla estatica, que no funcionaria por ej. en conexiones de dialup a ISP con IP dinamica
tenemos el objetivo MASQUERADE (enmascarar)
ejemplo:
iptalbes -t nat -A POSTROUTING -j MASQUERADE -o ppp0
DNAT todos los paquetes tcp destinados al puerto 80 que lleguen al interfaz eth1 hacia 1.2.3.4:8080
basicamente un ejemplo para configuracion de proxy transparente
NOTA DEL TRADUCTOR: aprovecho la pausa para aclarar las siglas
SNAT = Traduccion del Direcciones en el Origen
DNAT = Traduccion de Direcciones en el Destino
Ricardo Javier Cardenes Medina: Hay una cosa que Harald olvidó decir
y que ha comentado tras las preguntas
Las cadenas de la tabla nat sólo las atraviesa el PRIMER paquete de cada conexión
de manera que lo que hacen las reglas SNAT/DNAT/... es "establecer una correspondiencia NAT", lo que significa que almacena cierta información en una base de datos nat interna
Ninguno de los paquetes siguientes de esa conexión (en ambas direcciones) pasará por la tabla de NAT, sino que serán cambiados 'automágicamente'
(a todo esto, estamos esperando a que acabe el turno de ruegos y preguntas) O:)
DaniT: apartado 4 - mangling de paquetes
Ricardo Javier Cardenes Medina: mangling == "toquetear", "guarrear", hacer cambios varios, vamos :)
DaniT: mangling de paquetes es modificar parte del paquete que no es la direccion
Ricardo Javier Cardenes Medina: DaniT: Traduce por "manipulación" :)
DaniT: thx
Ricardo Javier Cardenes Medina: dnd (kudos to w8, que dirían los juanquers del intrenés)
DaniT: actualmente no tenemos muchos objetivos para manipulacion de paquetes
TOS manipula los bits de tipo de servicio en las cabeceras IPv4
TTL establece/incrementa/decrementa el TTL (tiempo de vida) de los paquetes
MARK - establece un campo interno de marca (nfmark/fwmark) a un cierto valor. usado basicamente para enrudado por politicas con iproute2 y QoS usando tc
ambos fuera del alcance de esta charla
ejemplo simple:
iptables -t mangle -A PREROUTING -j MARK --set-mark 10 -p tcp --dport 80
establece el campo MARK a 10 en todos los paquetes tcp con destino al puerto 80
segumiento de la conexion es otro apartado
conntrack esta implementado sobre netfilter (y no tiene relacion con iptables, por ej)
que hace conntrack?
sigue la pista a todas las conexiones estableceidas en las que esta involucrada la maquina local
esta informacion del estado de conexiones se usa por otras muchas partes de linux:
- el codigo NAT (traduccion de direcciones de red)
- para cortafuegos "stateful"
para cada paquete entrante al sistema, conntrack conecta la informacion acerca de a que conexion pertenece al hook PRE_ROUTING
significando esto que cualquier otro codigo del nucleo puede utilizar esta informacion de seguimiento a partir de ahora
seguimiento de conexion es nuevamente muy modular
tenemos un nucleo independiente "layer-four"
y modulos "layer-four" para tcp, icmp y udp
ademas otros protocolos extraños como IRC y FTP, tienen modulos de ayuda en el nivel de aplicacion
cualquiera puede escribir modulos para futuros protocolos capa 4/capa 5 y cargarlos dentro de conntrack
y que podemos hacer con esto?
por ejeplo poedmos usar esta informacion en cualquier regla de iptables
hay un criterio de iptables (el criterio de estado) que nos da la posibilidad de filtrar en base al estado del paquete
dividiomos los paquetes en:
NEW - el paquete establecera una nueva conexion, si lo aceptamos.
ESTABLISHED - el paquete pertenece a una conexion establecida
RELATED - el paquete esta relacionado con una conexion establecida
INVALID - el paquete no puede ser clasificado (multicast, broadcast, errores, ....)
RELATED es por ejemplo, conexion de datos de ftp relacionado con la conexion de control
o mensajes de error icmp en respuesta a paquetes tcp/udp
(necesita fragmentar, host/red/puerto inalcanzable, ...)
ejemplo
iptables -t filter -A FORWARD -j ACCEPT -m state --state ESTABLISHED
acepta todos los paquetes pertenecientes a conexiones ya establecidas
bien.. creo que es hora de terminar. hay muchas mas cosas que se pueden hacer con netfilter/iptables/conntrack/...
para mas lecturas, porfavor, diriganse a la pagina principal de netfilter en http://netfilter.gnumonks.org/
permanecere en el canal unos minutos mas para preguntas...
Mario: con iptables puedo redireccionar un puerto a una ip de otra maquina
Ricardo Javier Cardenes Medina: sí Mario
Por supuesto
Mario: con iptables puedo redireccionar un puerto a una ip de otra maquina?
Ricardo Javier Cardenes Medina: Tienes un ejemplo en la conferencia
Ricardo Javier Cardenes Medina: Un momento que lo busco
LaForge: ok, well, have a good night everybody. see you...
Ricardo Javier Cardenes Medina: iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -p tcp --dport 80 -i eth1
Ricardo Javier Cardenes Medina: see you LaForge :)
Ricardo Javier Cardenes Medina: Mario: Eso que ves ahí, redirige las peticiones TCP dirigidas al puerto 80 de la máquina (-p tcp --dport 80), que entren por la eth1 (-i eth1), a la máquina 1.2.3.4, puerto 8080 (--toto-destination 1.2.3.4:8080)
Ricardo Javier Cardenes Medina: Ups
Ricardo Javier Cardenes Medina: --to-destination, en lugar de --toto-destination
Ricardo Javier Cardenes Medina: O:)
Ricardo Javier Cardenes Medina: Mario ¿OK?
Capi: si el trafico se origina en la propia maquina tienes que poner OUTPUT en vez de PREROUTING
DaniT: bueno.. uno ke se kita el uniforme.. ;)))
Ricardo Javier Cardenes Medina: No Capi:
Capi: segun ponia en how-to creo que si
Ricardo Javier Cardenes Medina: OUTPUT y PREROUTING son cadenas en tablas diferentes
Ricardo Javier Cardenes Medina: OUTPUT es para filtrar
Ricardo Javier Cardenes Medina: PREROUTING es para cosas de NAT
DaniT: Capi: se trata de cambiar la direccion de destino del paqute antes de enrutarlo
Ricardo Javier Cardenes Medina: Amh, espera
Ricardo Javier Cardenes Medina: Que hay POSTROUTING, PREROUTING y OUTPUT
Ricardo Javier Cardenes Medina: Tienes razón
DaniT: por tanto va en el PREROUTING
Ricardo Javier Cardenes Medina: Se me había olvidado O:)
Capi: #$IPTABLES -t nat -A OUTPUT -p tcp -d 172.26.0.5 --dport 8080 -j DNAT --to 172.26.0.5:80
Ricardo Javier Cardenes Medina: De todas maneras, la última vez que miré, lo de OUTPUT lo tenían a medio hacer :???
Capi: ya decia yo
Ricardo Javier Cardenes Medina: O:)
Capi: es con lo del OUTPUT me volvi loco hasta que lo vi
Capi: y anda que no lo pone claro en el hot-to
Capi: y anda que no lo pone claro en el how-to
DaniT: capi: hablamos de redirigir un puerto a otra makina?
Capi: si
Ricardo Javier Cardenes Medina: O:)
DaniT: entonces creo que si
Ricardo Javier Cardenes Medina: DaniT: Pero redirigir los paquetes que se originan en la propia máquina
Ricardo Javier Cardenes Medina: DaniT: Pasa como con la tabla 'filter'
DaniT: PREROUTING y POSTROUTING son para paquetes que recibimos para FORWARD
DaniT: pero en este caso irian distinados a nuestra propia makina
Capi: OUTPUT espara rederigir lo que se genera en la propia maquina
DaniT: por tanto INPUT y OUTPUT
DaniT: bona nit, buneas noches, boas noites, good night, etc.. ;-)
DaniT: tamañana..