Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Introducción a Netfilter/IPTables

Seguridad
Por jcantero
departamento muros de fuego , Sección Software Libre
Puesto a las Thu Oct 3rd, 2002 at 11:03:43 PM CET
En las versiones 2.4 del kernel linux el viejo mecanismo de reglas de filtrado y NAT basadas en ipchains fueron sustituidas por un paradigma mucho más potente llamado NetFilter. De hecho, NetFilter no se encarga sólo del filtrado de paquetes y el NAT, sino que su mecanismo IPTables permite hacer incluso encaminamiento avanzado. Además, las capacidades de firewall se ven aumentadas más allá de un sencillo filtro de paquetes, ya que NetFilter/IPTables es capaz de seguir el estado de una conexión y establecer reglas para ellas. Este mecanismo de Linux tan potente y tan utilizado es examinado en esta didáctica Introducción a NetFilter/IPTables que realizan en IBM developerWorks.

 


< apt-get para Red Hat (13 comments) | 'Tremor' publicado bajo licencia BSD (0 comments) >
Enlaces Relacionados
· NetFilter
· Introducción a NetFilter/IPTables
· IBM developerWorks
· More on Seguridad
· Also by jcantero

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Introducción a Netfilter/IPTables | 7 comentarios (7 temáticos, editoriales, 0 ocultos)
Otro enlace de interés al respecto (4.30 / 10) (#1)
por dardhal a las Thu Oct 3rd, 2002 at 11:53:25 PM CET
(Información Usuario)

Como ya dice en la noticia, iptables es una herramienta que permite interactuar con la infraestructura netfilter para definir reglas de procesamiento de los paquetes (dejar pasar, NAT, marcado, etc.). Quizás la referencia más completa y actualizada acerca de iptables es el tutorial de Oskar Andreasson, que se encuentra aquí.

En cuanto a cuestiones de encaminamiento estático no tradicional, se ha podido hacer desde antes de existir netfilter (es decir, desde antes de los núcleos 2.4.x), en concreto desde núcleos 2.2.x de los primeros. De hecho las herramientas iproute (que incluye "tc", para control de ancho de banda, e "ip", que sustituye a "ifconfig", "arp", "route" y más) llevan bastante tiempo a nuestra disposición.

Si combinamos las posibilidades que ofrece iptables/netfilter con lo que aporta iproute (y la parte correspondiente de núcleo) con Linux podemos hacer casi cualquier cosa que se nos pase por la cabeza. Para más detalles acerca de qué se puede hacer y cómo, consultad esta web.



 
Analizar capas superiores (3.00 / 1) (#2)
por r00z a las Fri Oct 4th, 2002 at 02:07:44 PM CET
(Información Usuario) http://r00z.ath.cx/

El tema me interesa y he estado mirando qué puedo llegar a hacer con las herramientas que ofrece linux. Me interesaría poder analizar no sólo la connexión a bajo nivel (TCP y cía) sino también protocolos de más alto nivel cómo pueden ser el HTTP . Soporta el kernel estos protocolos o se utilizan otras herramientas en estos casos?
Principalmente me gustaría poder dar prioridad a ciertos protocolos y no tener que hacerlo a partir del TOS de cada paquete.



No es posible (al menos que yo sepa) (3.66 / 3) (#4)
por dardhal a las Fri Oct 4th, 2002 at 09:09:41 PM CET
(Información Usuario)

Según mis conocimientos del tema, no hay módulos para netfilter/iptables que permitan analizar el tráfico a nivel 7 (aplicación), es decir, que miren dentro de la parte de datos de los paquetes UDP o TCP y averigüen los comandos, respuestas y otras particularidades del protocolo para detectarlos o actuar en consecuencia. Es decir, no puedes poner (por ejemplo) una regla que diga "deja pasar todo el tráfico HTTP saliente desde la red interna", porque con Linux no tienes manera de saber si dentro del paquete va HTTP o FTP, por ejemplo.

No es que sea imposible, de hecho algunos "helper" ya existentes de netfilter/iptables hacen algo parecido a esto para superar las limitaciones de ciertos protocolos (FTP, IRC) en presencia de NAT. Otra cosa es que nadie se haya puesto a ello :-). Y puede que no fuera _tan_ difícil hacerlo, aunque sea de manera parcial. Por ejemplo para el HTTP podría ser tan "fácil" como analizar todos los paquetes que pasen para ver si en la parte de datos hay "GET URL HTTP/1.x" y respuestas correspondientes al anterior paquete, usando las facilidades del "connection tracking".

Pero claro, del dicho al hecho hay un trecho, y yo no soy capaz de hacer el "hola mundo" en C, como para que mi opinión al respecto sea relevante.

[ Padre ]


Puerto (none / 0) (#5)
por DopeRider a las Fri Oct 4th, 2002 at 09:52:26 PM CET
(Información Usuario)

porque con Linux no tienes manera de saber si dentro del paquete va HTTP o FTP, por ejemplo.

¿No se puede simplemente mirar el puerto?.

[ Padre ]


Las aplicaciones pueden estar en cualquier puerto (none / 0) (#6)
por dardhal a las Fri Oct 4th, 2002 at 10:56:43 PM CET
(Información Usuario)

Sí, se puede mirar sólo el puerto, y es posible que en ese puerto en lugar de estar la aplicación asociada a dicho puerto haya otra cosa diferente. Es evidente que en el caso más habitual si permites tráfico saliente hacia el puerto 80 estés permitiendo a la gente consultar páginas web, ¿ pero y si alguien configura su programa de P2P favorito o su emisora de MP3 en ese puerto ?. Pues que se te "saltan" el cortafuegos con un esfuerzo mínimo. Quizás las implicaciones de seguridad en este ejemplo sean reducidas, pero el ancho de banda es caro y los usuarios tienden a quejarse, y los jefes a enfadarse cuando su caro "canuto" se muestra saturado por tráfico indeseado.

[ Padre ]


No entiendo (none / 0) (#7)
por DopeRider a las Sat Oct 5th, 2002 at 01:35:40 AM CET
(Información Usuario)

Sí, se puede mirar sólo el puerto, y es posible que en ese puerto en lugar de estar la aplicación asociada a dicho puerto haya otra cosa diferente. Es evidente que en el caso más habitual si permites tráfico saliente hacia el puerto 80 estés permitiendo a la gente consultar páginas web, ¿ pero y si alguien configura su programa de P2P favorito o su emisora de MP3 en ese puerto ?. Pues que se te "saltan" el cortafuegos con un esfuerzo mínimo.

Creo que estamos hablando de varias cosas a la vez. Quien preguntó decía que quería "analizar", aunque parece que más bien quería dar prioridad.

La mayor parte del tráfico es conectarse a servicios externos. Vamos, que salvo los servidores de empresa, no hay, o no debe haber. La cuestión es a qué te conectas fuera. Ahí los puertos serán los estándares (si no, simplemente cortas) y puedes tratar cada uno según sus reglas.

Desconozco qué herramientas hay en Linux, pero me extraña que por ejemplo para HTTP no haya proxies que entiendan protocolos. Una función típica que he visto es filtrar según datos de protocolo.

[ Padre ]


 
Qos (none / 0) (#3)
por musg0 a las Fri Oct 4th, 2002 at 04:56:27 PM CET
(Información Usuario) http://helvete.escomposlinux.org

Me parece que tú lo que necesitas es Calidad de servicio.

Yo uso algunos scripts ya creados, porque no me apetece mucho ponerme en el tema y algo de mejora de rendimiento, como la latencia del ssh, sí he notado.

[ Padre ]


 
Introducción a Netfilter/IPTables | 7 comentarios (7 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda