Gente querida,
Pueden encontrar en http://netsecure.com.ar/2010/05/20/manual-tutorial-de-hping-con-ejemplos-i/, el primer artículo que conformará un manual lo mas completo posible de Hping y sus posibles usos, con los ejemplos necesarios, para aprender a explotarlo a full.
Espero que les guste!
Para seguir evaluando las difrencias y similitudes en ambas plataformas (ver parte 1), trataré de ir haciendo una muestra de equivalencias en ambos sistemas, para que pueda ser usado como «diccionario» para los habitantes de estos dos mundos.
En el mundo de los sistemas, conozco un solo sistema operativo anarquico, es decir, donde cualquier usuario puede llegar a cambiar cualquier configuración, pero no es el tema de este artículo, si no por el contrario, tanto linux como IOS (sistema operativo de CISCO), necesitamos ciertos privilegios en el sistema para poder cambiar una configuración.
Basicamente, en linux tenemos a los usuarios, los grupos, y el usuario root.
Los permisos se otorgan mediante distintos permisos en los archivos, siendo que los archivos tienen un dueño (un usuario), tambien tienen un grupo, el cual es un conjunto de usuarios. De esta manera, linux puede distribuir ciertas responsabilidades en distintos usuarios. Sin embargo, el poder de todo lo tiene el usuario «root» (esto no es nada particular de linux, si no mas bien de los sistemas operativos unix).
Así cuando querramos configurar algo en nuestro linux deberemos tener acceso al usuario root.
Podemos pasar de usuario común a root de la siguiente manera:
usuario@myhome:~$ su - root Password: myhome:~#
Tipicamente, en los unix, ver el signo # significa tener los permisos de superusuario (root).
Algo parecido (en realidad identico pero enmascarado), sucede en los sistemas IOS.
Cuando iniciamos por primera vez un router cisco, y nos conectamos mediante una terminal (hyperterminal o minicom), vemos esto:
Router>
Que significa que solo tenemos acceso a un limitado número de comandos, para poder ejecutar comandos que afecten a la configuración del router debemos ejecutar el comando «enable».
Router>enable Router#
Como vemos el prompt, nos muestra el signo #, que nos indica que tenemos los permisos equivalentes a root, en un sistema unix.
En este caso, ejecutar el comando enable nos transforma automaticamente en superusuarios, sin embargo, cuando se configura un router, mas que para realizar unas pruebas, se establece una contraseña, asi mismo, se puede establecer una contraseña para el usuario mas básico, de forma tal que nadie que no conozca la contraseña pueda siquiera husmear en el router.
Router>enable Password: Router#
Al instalar un IOS, lo primero que debemos hacer es configurar una contraseña,
para estar mas seguros de que nadie meterá las narices donde no debe.
Tanto IOS como linux, tienen mecanismos similares de autenticación, en el caso de linux pueden ser mucho mas avanzado, sin embargo no suelen tener mucha reelevancia si queremos que actue solo como router.
Una diferencia, que si bien es simple, pero importante, es como ambos sistemas, es la forma en que estos guardan los cambios efectuados.
En ambas plataformas, los cambios de configuración se hacen inmediatamente al ejecutar el comando, sin embargo, este cambio solo dura, hasta que se reinicie el equipo. Para perdurar los cambios mas allá de los reinicios, en las plataformas cisco, debemos ejecutar el comando «write», este comando guarda todas los cambios realizados en el equipo, y volveran a ser levantadas una vez que se reinicie.
En linux, no existe un comando tan general que guarde todos los cambios realizados, si no que cada configuración o variable, tiene su o sus archivo/s. En las siguientes secciones revisaremos esos archivos y la forma analoga de hacerlo en cisco.
Algo fundamental en cualquier dispositivo de red, es poder configurar las interfaces de red.
Compararemos los siguientes puntos, para hace un primer «approach», en estas equivalencias entre cisco y linux.
En este post nos encargaremos de analizar y comparar estos puntos.
Configuración básica
Salvado de información
Visualización de datos
Para asignara una dirección de red a una interfaz en linux (como root):
ifconfig eth0 192.168.1.1 netmask 255.255.255.0
Aún que vale recalcar que esto se mantiene por compatibilidad con los unixs, ya que la mejor manera de configurar las interfaces en linux, es con el pack de utilidades iproute2, que se haría de la siguiente manera:
ip addres add 192.168.1.1 dev eth0
Para agregar una descripción podemos agregarla en los archivos de configuración que veremos mas abajo.
En un router cisco, lo hariamos de la siguiente manera:
Router>enable Router#config t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface FastEthernet 0/0 Router(config-if)#no shutdown Router(config-if)#ip address 192.168.1.1 255.255.255.0
Al momento de ejecutar el comando enable, el router puede pedirnos un password, este password se configurar
en la instalacion del router, aunque puede quedar sin password, como en este caso.
Para agregar una descripción podemos usar:
Router(config-if)#description "Ethernet conectada a la dmz" Para configurar el hostname de un router Cisco:Router>enable Router#config t Router(config)#hostname MyRouter MyRouter(config)#exit MyRouter#writeEl "write" graba todos los cambios hechos, por lo cual insisto en ser cuidadosos con este comando, por que si ademas de cambiar el nombre, cambiamos otra cosa, quedará grabado al ejecutar "write"
En linux, necesitamos ser root, y lo hacemos de la siguiente manera:gustavo@Onix:~$ su - Contraseña: Onix:~# hostname MyHostname Onix:~#Como vemos, el comando es igual que en cisco, sin embargo, pareciera ser que no cambia automáticamente el hostname, sin embargo si es asi, solo que el hostname que vemos en nuestra consola ( Onix:~# ) es una variable que se configura en el momento que iniciamos sesión. Por lo tanto, si ejecutamos el comando exit, y volvemos a loguearnos, ya aparecerá el nombre cambiado.
Otra forma de cambiar el hostname, es ejecutando:Onix:~# echo "MyHostname" > /proc/sys/kernel/hostnameDe todos modos, el hostname no cambiara en nuestra consola, hasta que loguemos de nuevo.
Los comandos vistos recientemente, no cambian el hostname de nuestro linux permanentemente. Para hacerlo permanente mente, debemos editar el archivo: /etc/hostnameEn este caso no necesitamos editarlo con un editor, ya que es solo una linea la que hay que cambiar:
echo "MyHostname" > /etc/hostnameSalvado de configuración de las interfaces
Tanto en Cisco, como en Linux, los cambios explicados arriba, se pierden a la hora de reiniciar el equipo. Los dos sistemas tienen formas de guardar esta información, a saber:
En una distro tipo Debian el archivo es: /etc/network/interfaces
En los sistemas tipo RedHat el archivo es: /etc/sysconfig/network-scripts/ifcfg-[nombre de la intefaz]
Para poder editar estos archivos usamos cualquier editor de texto instalado. Generalmente Vi.
Una vez editado el archivo correspondiente, los cambios no se aplican hasta que reiniciemos los scripts de red.En la plataforma Cisco, una vez realizado el cambio pretendido, si se quiere guardar dicho cambio, se hace de la siguiente manera:
Router(config-if)#ip address 192.168.1.1 255.255.255.0 Router(config-if)#exit Router(config)#exit Router#write Building configuration... [OK] Router#Este comando, guarda todos los cambios realizados en el router, por lo cual hay que tener cuidado al utilizarlo, por que podemos estar guardando algun otro cambio que hayamos realizado.
Visualización de datos
En ocaciones necesitamos visualizar cierta información de las interfaces, en Cisco podemos hacerlo de la siguiente manera:
Router>show interfaces FastEthernet0/0 is administratively down, line protocol is down (disabled) Hardware is Lance, address is 00e0.8f0d.d501 (bia 00e0.8f0d.d501) Description: "Ethernet conectada a la dmz" Internet address is 192.168.1.1/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set ARP type: ARPA, ARP Timeout 04:00:00, Last input 00:00:08, output 00:00:05, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 input packets with dribble condition detected 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out ....Este comando nos lista abundante información de todas las interfaces de red.
En Linux ejecutamos:
Para ver información sobre una sola interfaz:
/sbin/ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:16:17:77:cd:1b inet addr:192.168.1.3 Bcast:192.168.1.7 Mask:255.255.255.248 inet6 addr: fe80::216:17ff:fe77:cd1b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4606 errors:0 dropped:0 overruns:0 frame:0 TX packets:3338 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:384745 (375.7 KiB) TX bytes:602690 (588.5 KiB) Interrupt:250 Base address:0x2000Para ver info de todas las interfaces:
/sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:16:17:77:cd:1b inet addr:192.168.1.3 Bcast:192.168.1.7 Mask:255.255.255.248 inet6 addr: fe80::216:17ff:fe77:cd1b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4606 errors:0 dropped:0 overruns:0 frame:0 TX packets:3338 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:384745 (375.7 KiB) TX bytes:602690 (588.5 KiB) Interrupt:250 Base address:0x2000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4112 errors:0 dropped:0 overruns:0 frame:0 TX packets:4112 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:176739 (172.5 KiB) TX bytes:176739 (172.5 KiB)Con el comando iproute, podemos visualizar sobre una sola interfaz de la siguiente manera:
ip address list eth0 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:16:17:77:cd:1a brd ff:ff:ff:ff:ff:ffó
ip address list 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:16:17:77:cd:1b brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/29 brd 192.168.1.7 scope global eth0 inet6 fe80::216:17ff:fe77:cd1b/64 scope link valid_lft forever preferred_lft foreverpara ver la info de todas las interfaces.
En los siguientes posts veremos algunos detalles mas avanzados, relacionados con el ruteo en ambos sistemas.
/* A partir de marzo nos estamos mudando a http://netsecure.com.ar o http://www.netvulcano.com.ar */
Hemos visto en otros articulos, que IpTables, es la herramienta en espacio de usuario, que permite establecer filtros con NetFilter, el cual es parte del kernel de Linux. Pero independientemente de las herramientas en espacio de usuario, existe una forma de indicar al kernel, como manejar ciertoas cosas. Esta forma es, a saber, mediente el directorio /proc
No tengo que detenerme mucho sobre le directorio /proc, ya que basta googlear para encontrar información sobre este pseudo sistema de ficheros. Solo basta decir que mediante el proc podemos acceder a información del kernel, y modificar «on the fly» ciertas configuraciones.
Por ejemplo en /proc/sys/kernel/hostname encontramos el hostname de nuestro linux, y lo cambiamos haciendo
echo otroHostname > /proc/sys/kernel/hostname
De esta misma manera, podremos cambiar «a mano» ciertos valores del funcionamiento del kernel, y consecuentemente, el comportamiento del networking del mismo. Sin embargo, existe una manera mas «prolija»: sysctl (fijate que si no existe el archivo (es decir no existe la funcionalidad), con esa redirección lo crearemos, pero no implica que afectará en manera alguna al funcionamiento del kernel).
Sysctl, nos permite configurar las mismas variables (ver mas abajo) que esten configuradas en el /proc/sys , de forma centralizada en el archivo /etc/sysctl.conf. Siendo su sintaxis muy simple:
clave.a.configurar = valor
Para no ahondar mucho sobre el tema, simplemente hagamos un breve repaso y vayamos a lo importante
Breve repaso:
sysctl -a # muestra todas las variables configurada
sysctl -w kernel.hostname=MyHaxorName # asigna "MyHaxorName" como hostname del sistema
sysctl kernel.hostname # muestra el valor asignado a la variable
echo "kernel.hostname = MyHaxorName" >> /etc/sysctl.conf # cada vez que se inicie el sistema, sysctl configurará
las variables como se encuentran en este archivo
A continuación, una lista de las variables mas importantes a tener en cuenta para la seguridad de nuestro firewall
En /proc/sys/net/ipv4/conf tenemos una carpeta por cada interfaz de red (eth0, lo, wlan0.. etc, además de las carpetas default y all). En cada una de ellas, encontramos archivos que configuran comportamiento especifico de cada interfaz, en el caso de rp_filter, es un filtro anti spoof: solo permite que la respuesta a un paquete sea enviada por la misma interfaz por la cual se recibió el paquete.
Habilitamos con 1, deshabilitamos con 0.
Bastante conocido, con un 1 en este archivo, ignoramos todos los paqutes ICMP tipo echo, es decir, los pings.
El no responder pings, permite que pasemos desapercibidos en algunos escaneos simples, pero también nos bloquea la posibilidad de hacer pruebas de pings.
El ataque syncooky conciste en enviar muchos paquetes TCP con el flag SYN activado, pero no completa el HandShake, por lo que ocupa memoria en conexiones que quedan a la espera, causando un DoS. Colocando un 1 en este archivo, le pedimos al kernel, que no abra un buffer hasta que la conexión este abierta.
Envia señales a syslog cuando entran paquetes de redes ilegales (cuando el kernel no sabe como rutearlas).
Un paquete ICMP Redirect, informa cuando hemos mandado un paquete a travez de una ruta que no es la optima.
Un ejemplo casero, es cuando tenemos ROUTER1 conectado a internet y a la LAN, en la cual existen 2 pc (PC1 y PC2), la configuración normal seria configurar a PC1 y PC2 con Default Gatewat en ROUTER1. Si cometieramos la tontera configurar PC2 con su default gateway en PC1 (teniendo por Default Gateway a ROUTER1 en esta pc) PC1 nos informaria que hay una ruta mas directa, y es atravez de ROUTER1. Esa funcion de anunciar esa ruta la cumple los paquetes ICMP Redirect. Con este tipo de paquetes, «alguien» podría realizarte un MITM.
La explicación de esta variable esta explicada en Paquetes ICMP Redirect, pero en este caso, implica no enviar dichos paquetes ICMP.
Si tu linux no actua como ruter, en una red con varios routers, lo mas aconsejable es deshabilitarlo, poniendo un 0.
En este archivo podemos colocar un numero, el cual será la cantidad máxima de conexiones IP que el kernel puede manejar. Este numero suele estar fijado segun la cantidad de memoria ram que poseamos. Esto puede ser un punto clave a la hora de lidiar con DoS. Asi mismo, podemos encontrar unos cuantos archivos similares, pero más especificos, haciendo ls /proc/sys/net/ipv4/netfilter/ip_conntrack*, los nombres de cada uno dan una idea de funcionalidad, y si conoces bien el funcionamiento del protocolo IP podrás retocar estos valores.
Cuando internet nacio, inocentemente creia que todos serían buenas personas, por lo que sus protocolos, permitian a cualquiera obtener mucha información, en este caso, Ipv4, permite que solicitemos a un determinado host, una ruta especifica por donde enviar paquetes, pudiendo ser utilizada esta información para conocer las «Relaciones de Confianza» entre routers. Fuera de eso, hoy en dia no se usa. Lo deshabilitamos con un 0
ICMP tiene la facultad de poder enviar paquetes Broadcast, es decir, enviar un paquete, el cual todos los hots reconoceran como enviados hacia si mismos, ya que el destino de dicho paquete es una dirección de broadcast. Al recibir este paquete, el host actua en consecuencia y lo responde. Si todo funcionara como corresponde, no habria problema con esta funcionalidad… pero si «alguien» decide enviar paquetes ICMP Broadcast a una gran lista de IPs con un «source» spoofeado, todos los IPs de la lista enviarian una respuesta a la IP inocente (la spoofeada), causandole probablemente un DoS. Para evitar que nos usen como «reflector» enviandonos paquetes broadcast, ignoramos dichos paquetes colocando un 1 en este archivo.
El RFC 1122, nos pide que los paquetes ICMP erroneos sean completamente descartados silenciosamente, para no probocar tormentas de broadcast. Para cumplir con dicho requerimiento, colocamos un 1 en dicho archivo.
Conocida por todos, esta variable, habilita o deshabilita el reenvio de paquetes. En los casos donde nuestro linux haga NAT, debe estar habilitada, en caso contrario, es recomendable deshabilitarlo.
Tiempo en segundos que esperaremos antes de descartar una conexión parcialmente cerrada, por defecto 60 segundos, ya que así lo pide el RFC correspondiente a TCP, pero si queremos podemos disminuirlo a fin de evitar algún DoS.
Cantidad de segundos que esperará el kernel, antes de enviar un paquete para mantener abierta la conexión, a pesar de que no esta siendo utilizada momentaneamente. Por defecto el valor es 7200 (2 horas), pudiendo ser reducido en algunos casos a 1 hora o 1/2 hora, en segundos 3600 o 1800.
/proc/sys/net/ipv4/conf/all/proxy_arpCon un 0 podemos deshabilitar esta funcionalidad, que no suele ser necesaria, a menos que seamos servidor de VPN, Firewall o Router que lo requiera.
/proc/sys/net/ipv4/neigh/[interfaz de red]/gc_stale_timeLos segundos que configuremos en esta variable, definiran el tiempo en que se actualiza el cache ARP. Dicho cache, es el que se envenena cuando se realiza un ARP Poisoning Attack, por lo que cuanto mas bajo sea, mas vulnerable a este ataque, pero al mismo tiempo, mas rapido sabremos cuando una IP quedo fuera de servicio o una MAC cambio de IP (arp -n para verificar las entradas del cache y su estado)
Dicha variable, habilita (con un 1) o deshabilita (con un 0) la posibilidad de que la conexión TCP negocie el tamaño de la ventana. Dependiendo del segmento de la red y la topologia de la misma, suele ser conveniente que esté habilitada, sin embargo, nos expone a ciertos escaneos (nmap windows scaling) y a posibles DoS.
SACK es un algoritmo para detectar perdidas de paquetes. Si habilitamos dicha opción (colocando un 1) siempre y cuando pueda, TCP lo utilizará, en caso contrario, ignorará dicha opción. Es recomendable habilitar dicha opción, ecepto que nuestras conexiones TCP las hagamos en un ambito sin demasiadas perdidas de paquetes.
En este archivo no colocaremos ni un 1 ni un 0, si no que colocaremos de números, que definiran un rango de puertos, el cual será utilizado para puertos locales, es decir, puertos desde donde comenzaremos conexiones hacia el exterior. En general el rago es 1024 a 4999, pero es conveniente ejecutar:
#echo "32768 61000" > /proc/sys/net/ipv4/ip_local_port_range
en sistemas donde se usen los puertos 1024 a 4999 para brindar servicios.
TTL es Time To Live, o bien, el tiempo de vida que le otorgaremos a los paquetes generados por nuestro host. Este «tiempo» no se cuenta en segundos, sino en cantidad de routers que puede atravesar antes de ser descartado (morir). Es asi que cada router, descuenta uno a dicho valor.
Llegar de sudamerica a china nos cuesta de 12 a 20 saltos, por lo que un paquete que tenga mas de 30 saltos es un tanto raro. El valor mas recomendado en general es 64 (traceroute y a sacarnos las dudas)
Como lo recita su nombre, ECN es una opción de TCP que permitenotificar cuando un host esta congestionado, para que se busque otra ruta. Algunos firewalls o routers pueden llegar a filtrar los paquetes que tengan esta opción habilitada, pero son los menos. Habilitamos con un 1, que sería lo mas recomendable.
A la hora de armar un Firewall para nuestro linux, no es cuestión de ejecutar cualquier script a fin, si no conocer bien que es lo que necesitamos, para que y como. El conocer estas variables nos permite conocer donde debemos tocar en caso de ser necesario. Para complementar este conocimiento recomiendo leer las fuentes expuestas mas abajo y leer los siguientes artículos: NetFilter / IPTables I, II, III, IV, V
Fuentes:
http://www.securityfocus.com/infocus/1711
http://ipsysctl-tutorial.frozentux.net/chunkyhtml/tcpvariables.html
http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html
/* A partir de marzo nos estamos mudando a http://netsecure.com.ar o http://www.netvulcano.com.ar */
Podés estar preguntandoté por que realizar una comparación entre cisco (reyes indiscutibles de las grandes redes) contra el kernel linux, utilizado principal mente para brindar servicios de red, es probable, que opines que es como comparar Papas con frutillas.
He aquí la respuesta: Sin duda, cada uno ocupa un lugar que no puede ser remplazado por el otro, empero, hay una zona gris, donde si bien puede usarse un router cisco, también puede usarse un servidor linux, ahorrando costos y teniendo muchos mas beneficios. Otra de las razones, es que con una serie de artículos que cubran las diferencias y similitudes entre ambos, quienes conozcan de cisco podrán aproximarse al mundo linux de manera mas simple, y viceversa.
Cabe mencionar, que existe un proyecto llamado FREESCO, el cual intenta proveer en un solo disquette un sistema operativo (kernel linux) que suplante a los productos de CISCO o 3COM.
Cisco provee una cantidad enorme de productos, dentro de los cuales los firewalls, los routers y los switch son los mas conocidos y abundantes. CISCO suele innovar en los protocolos y funcionalidades de dispositivos de red, y es el referente mas grande del mundo en cuanto a Networking.
Linux por su parte es un kernel, con varios años de desarrollo, al igual que los kernels BSD tiene carácteristicas importantes cuando hablamos de ruteo o firewalls, por sobre eso, las distribuciones GNU/Linux, son tan abundantes que pueden instalarse en varios tipos de arquitecturas de servidores (incluso mainframes) y PCs de escritorios.
Para empezar, debemos hablar sobre la diferencia de Hardware, la cual es muy importante en esta comparación.
Hardware
Linux, ha demostrado ser un de los kernels mas portables, exceptuando NetBSD (que sin duda es el kernel mas portado) Linux ha podido instalarse en Mainframes (la famosa BlueGene) y hasta en pockets pc o telefonos celulares. Esto nos da la ventaja de poder instalar linux en casi cualquier hard disponible.
Si bien esto nos da mayor flexibilidad, cuando lo comparamos con CISCO, debemos entender que todo el hard de cisco, esta especialmente integrado, ayudando a que el software haga uso de las capacidades a nivel firmware.
Otra punto importante a evaluar, es la fidelidad.
Es probable, que un hard CISCO, tenga una mayor fidelidad que una pc cualquiera. Para poder usar una PC, deberiamos eliminar los discos con partes mobiles (suplantandolós por disco de estado solido) , lo cual son la parte mas sensibles de las PC junto con la alimentación electríca y la temperatura.
Es decir, que el hecho de que Linux se pueda instalar en cualquier hard, no significa necesariamente, que nos saldrá mas barato, pero sin duda, si que nos da mayor flexibilidad desde cualquier punto de vista.
Sin embargo, Linux tomará ventaja, cuando pensemos que a la pc podemos remplazar cualquiera de sus partes para mejorarla, o reemplazar alguna parte dañada.
Tanto en el hard cisco como en el que puede instalarse un Linux, son unidades de procesamiento, y las capacidades dependerán fundamentalmente del costo que estemos dispuestos a gastar. Para poder hacer una correcta comparación, se debe evaluar el ámbito de aplicación, ya que en ciertos casos es mas fácil usar un router cisco, y en otros, será mas facil instalar una pc con un linux instalado especialmente para routear.
Características
Consideraremos al ruteo, o las funcionalidades de un firewall como un servicio que puede ser brindado por un nodo de la red, para poder comparar de manera cuantificable las características de CISCO contra Linux.
Depende del costo que gastemos en un router cisco, podremos obtener mas servicios y características. Fundamentalmente CISCO provee en sus dispositivos servicios de ruteo avanzado, con protocolos como RIP(v2,ng), BGP, EIGRP, GRP, OSPF, y demás, los cuales permiten realizar sistemas complejos de ruteo, de una manera bastante simple. Todo esto se puede combinar con STP, para lograr una rápida y segura convergencia de la red.
Sin embargo, aunque con un poquito mas de esfuerzo (verdaderamente muy poco) podemos tener exactamente los mismos servicios, en un server con alguna distro GNU/Linux, pero a esos servicios podemos agregarle los servicios «clásicos» brindados por un servidor Unix, llamese, NFS, CIFS, DNS, FTP, SSH, HTTP, IRC, y bue.. no se, 65000 mas. Lo que en verda quiero decir, es que en un linux podemos implementar ciertos servicios adicionales que sirvan a la red de usuarios, y aún si fueramos puristas y quisieramos tener un dispositivo que solo rutee, las posibilidades de selección de ruta son mucho mejor, como ya intentaremos mostrar.
Por sobre esto, hay muchas herramientas, para obtener estadisticas, o para detectar errores de red o de aplicaciones (por ejemplo sniffers, scanners etc).
A pesar de todo eso, esto no hace que Linux sea la opción ideal, ya que todas estas características pierden importancia cuando pensamos, que si bien podemos llegar a necesitar algunas de ellas, probablemente no lo necesitaremos en todos los nodos, por lo que la simpleza de los dispositivos embebidos puede disputarle la punta según la necesidad.
Un punto mas a considerar, es el esfuerzo a la hora instalar un fix o una version nueva del software.
En el caso de CISCO significa un indisponabilidad segura, ya que para updatear necesitamos reiniciar, en Linux, solo necesitamos reiniciar completamente, es caso de que se trate de un update en el kernel, pero si se trata de alguno de los servicios, es sabido que solo necesitaremos reiniciar el servicio.
Sin duda, en muchos casos Linux, llevará la punta en cuanto a cantidad de aplicaciones que podemos implementar sobre el, en comparación con la poca flexibilidad que nos ofrece CISCO, a la inversa, la simplicidad y minimalidad de CISCO es una ventaja que puede volcar la balanza a su favor.
Conocimientos
Al comparar ambas posibilidades, debemos tener en cuenta los conocimientos necesarios para poder operar cualquiera de los dos.
Sin embargo, no voy explayarme sobre esto, ya que en los sucesivos artículos trataremos de comprar ambas posibilidades, y conocer las dos formas de hacerlo, ya que considero, que los administradores eligen una u otra cosa, dependiendo del conocimiento que tienen de una u otra tecnología, dejando en segundo plano los otros puntos a considerar.
Espero que se vayan dejando bien sentadas las diferencias (ventajas y desventajas) y cualquier acotación será mas que bienvenida, seguimos en el próximo artículo!.
El 18 de Marzo (un poco menos de 3 meses) Patrick McHardy informo en la lista de desarrollo de NetFilter, el nuevo release de futuro sucesor de IPTables, llamado Nftables, intentando quizas, recordar que IPTables es solo la interfaz de usuario de NetFilter. Lo cierto, es que merece un first approach.
Nftables fue escrito desde cero, y su codigo incluye el código de implementación en el kernel, la libreria libnl y la interfaz de usuario nftables.
Algunas características que me pareció interesante destacar de kernel:
– La primer diferencia que merece ser mencionada, es la posibilidad de asignar mas de un Target a una regla, esto ya de por si, puede reducir en gran parte, la cantidad de lineas de nuestro script de iptables.
– Los contadores, ya no vienen por defecto, pero estan para aplicarlos opcionalmente
– La sintaxis se chequea en espacio de usuario, el kernel solo hace lo que se le ordena (tenga o no sentido)
Con respecto a la intefaz de usuario:
Básicamente la sintaxis se compondrá de Expresiones de descripción de datos en tiempo de ejecución, las cuales son nada mas ni nada menos que las características de los paquetes, Constantes, por ejemplo «10.0.0.0/27», «53», o «192.168.1.1», Expresiones de relación y operadores, es decir los conocidos «equal», «non-equal», etc, Enumeraciones o listas, al estilo «22-1025», o «{ 80, 8080, 443 }» o las listas de flags tcp, y finalmente, las acciones o targets ( log, drop, accept etc.)
En fin, un cambio que supongo será muy bien visto por la comunidad.
Estoy ansioso por probar Nftables, tanto que voy a hacerlo, y cuando tenga noticias les contaré un poco mas….
En el primer artículo sobre IpRoute pudimos aproximarnos al uso cotidiano y casero que le podemos dar a esta poderosa herramienta,
pero en esta ocasión vamos a avanzar sobre utilidades mas avanzadas.
IpRoute no solo centraliza la administración de la red en nuestro linux, si no que nos brinda herramientas que antes uno
no podía ni imaginar, sin pagar un alto costo por sistemas dedicados. Por ejemplo: Proxy ARP, control del ancho de banda, multicasting,.. y una de las cosas que mas me interesa es la posibilidad de trabajar con múltiples tablas de ruteo (balanceo de carga).
Con IProute podemos manejar las distintas tablas de ruteo del kernel de linux.
Simplificando ideas, tener varias tablas de ruteo, nos permite acceder a distintas redes con el agregado de poder elegir de forma minuciosa (ya sea por dirección de destino, Type of service, scope, o interfaz de salida) la ruta a seguir de un determinado paquete (como adelanto, imaginate si pudieras usar el poder de matcheado de iptables, para marcar un paquete, el cual direccionaremos a la tabla de router que querramos! ).
Ejemplos de uso:
Tipico ejemplo, tengo dos conexiones a internet, una de 3mb con Fibertel y una de arnet de 1mb.
Atraz de Linux’sBox tengo un servidor de juegos, y una red de maquinas que acceden para navegar y usar msn y otra que se conecta a juegos online.
Objetivo: Distribuir las maquinas entre las 2 conexiones para que la red no se me sature.
Otro ejemplo común, es cuando tengo dos conexiones, y quiero balancear el uso de p2p en la red.
En mi caso hoy quiero utilizar estas herramientas para balancear trafico http entre dos proxyweb
Comenzando:
El kernel soporta 256 tablas de ruteo (de la 0 a la 255), lo que es generalmente, mas que suficiente.
Por defecto se le asigna el numero 255 a la tabla de ruteo local, la cual en la mayoría de los casos no tocaremos, ya que esta contiene los broadcast y direcciones de las interfaces locales, esta tabla es la que manejan los ip address e ifconfig, para poder verla usamos: ip route show table local.
El número 254 se lo gano la tabla principal (main) donde esta alojadas las rutas que soliamos ver en un route -n y finalmente, siempre hay algo que debermos explicar en otro momento, y en este caso nos referimos a las tablas 253 (default) y 0 (llamada para unspect , sirve para manejar todas las tablas! :s )
Esta configuración esta guardada en /etc/iproute2/rt_tables#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
Y es justamente en este archivo donde definiremos nuestras tablas personalizadas.
Como es costumbre en un sistema *nix-like, usamos nuestro editor de texto preferido y nos disponemos a editar este archivo,
donde colocaremos un ID y un ALIAS, el ID debe estar entre 1 y 252 ya que los otros valores están ocupados, el alias sera el nombre que le asignaremos
a la tabla para llamarla de una forma amigable.
Una vez editado nuestro archivo puede quedar algo asi:# reserved values
#
255 local
254 main
253 default
0 unspec
#
# Tablas personalizadas
#
# Tabla para Red Arnet
1 arnet
# Tabla para red Fibertel
2 fibertel
Simple no? si, por ahora es asi de simple.
Usando ip route show table arnet/fibertel , podemos observar que no hay nada dentro de las tablas.
Ahora bien, dentro de cada tabla, puede haber varios tipos de rutas, y estos son:
Unicast:
La mas común de todas las tablas, tan común, que cuando no sepamos de que tipo es una ruta, muy probablemente sea Unicast.
Este tipo de rutas, establece una gateway para una red.
Por ejemplo, cuando queremos llegar a la red 10.1.1.0/27 (ver subnetting) atravez de nuestro router (cuya ip es 192.168.1.1) usaremos:
ip route add 10.1.1.0/27 via 192.168.1.1
Y el ejemplo mas común es el de la ruta de ultima milla, ruta por defecto, puerta de enlace, o default gateway:
ip route add default gw 192.168.1.1
ó bien
ip route add 0.0.0.0/0 via 192.168.1.1
Broadcast:
Otra ruta muycomún. Esta tipo de ruta, solo se encuentra en la tabla local, y especifica una dirección de broadcast de una interfaz.
Para mirar esas rutas podemos usar:
ip route show type broadcast table local
Lo que nos mostrara solo las rutas tipo broadcast de la tabla local
Local:
Tan comunes como las broadcast, las rutas del tipo local, quienes pueden ser un poco complicadas de explicar por un concepto poco logico, para la forma de pensar humana, ya que, esta ruta, dice, para llegar a la dirección 10.0.0.1 parta de la interfaz eth1 y use 10.0.0.1 como dirección de origen.
que??
Si bueno, miremos esto:
Agregamos una dirección ipv4 a nuestra interfaz eth1
ip addr add 10.0.0.1 dev eth1
Veamos lo siguiente:
ip route sh type local table local
Veremos que automaticamente, se ha agregado la si siguiente linea:
10.0.0.1 dev eth1 proto kernel scope host src 10.0.0.1
Con esto, si hacemos un ping a dicha ip (10.0.0.1) funciona de 10, pero si la borramos (ip route del 10.0.0.1 dev eth1 table local),
veremos como el tonto de nuestro kernel no sabe como llegar!!!!
Entonces, este tipo de rutas, como dijimos, le dicen al kernel, que para llegar a la ip 10.0.0.1 user la interfaz eth1, con la dirección 10.0.0.1.
Volvamos a los tipos de rutas
nat:
Tipo de ruta utilizada cuando se crea NAT
unreachable:
Este tipo de rutas se generan automáticamente cuando se recibe un paquete ICMP unreachable.
prohibit:
Exactamente igual a unreachable pero con ICMP prohibit
blackhole:
Este tipo de ruta es similar a /dev/null, es decir, lo que matchea contra esta ruta, es descartado
throw:
Si blackhole es un /dev/null throw es un archivo tipo pipe (fifo), es decir, cuando una conexión llega a matchear contra esta ruta, se envia a la conexión nuevamente a ser manejada por el proceso de selección de ruta normal, con un destino especifico.
Pues bien, teniendo una idea, de como crear rutas, y de como funcionan (siempre teniendo en cuenta el comando ip route get), podemos crear las rutas que necesitemos en nuestras tablas personalizadas, por ejemplo:
Hagamos un mini ejemplo de como conectarnos a dos proveedores
#Vale aclarar primero, que si no tenemos una interfaz para llegar a 10.0.0.2 habrá un error
#además estoy suponiendo que ya creaste las tablas arnet y fibertel en /etc/iproute2/rt_tables
#Ahora si insertamos una ruta por defecto en la tabla arnet
ip route add default via 10.0.0.2 dev eth1 table arnet
# y otra en la tabla fibertel
ip route add default via 192.168.5.1 dev eth2 table fibertel
Ahora bien, antes de seguir, para entender la siguiente linea, quizas necesites leer los articulos de NetFilter, para comprender que estamos haciendo.
iptables -t mangle -A OUTPUT -p tcp –dport 80 -j MARK –set-mark 1
iptables -t mangle -A OUTPUT -p tcp –dport 1863 -j MARK –set-mark 2
Con esto solo nos falta unas lineas mas,
ip rule add fwmark 1 table arnet
ip rule add fwmark 2 table fibertel
Analicemos esto un poco:
Al igual que con los otros objetos, podemos listar el contenido de la tabla rule con
ip rule list
nos mostrará algo asi:
Onix:~# ip rule ls
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Estas reglas (rules) determinan la forma en que los paquetes ingresaran en una tabla u otra. Si ya te has familiarizado con el funcionamiento de tablas, podrás notar,
que en este caso, los paquetes entran primero en la tabla local, ya que de seguro, es la primera contra la cual matchearan (anteriormente explicamos su uso). Al salir de
esta tabla, pasaran a la tabla main, donde encontraran su destino.
Para entender de forma práctica el uso de ip rule, podemos ver una forma alternativa de hacer lo mismo que hicimos con ‘ip rule add fwmark……’:
ip rule add from 192.168.1.0/24 table arnet
Y con eso, diriamos que todo lo que venga de la red 192.168.1.0/24 pasa a ser controlado por la tabla arnet.
fwmark nos permite leer una marca (que asigno iptables, y que es solo de uso interno) a un determinado paquete, y según esa marca destinarlo a una tabla.
Ahora pensemos que el poder de matcheado de IPtables nos permitirá dirigir el tráfico de la forma que necesitemos.
Un resumen de todo:
Primero, definimos tablas de ruteos, a las cuales le asignamos un default gateway. De esta manera nuestras tablas quedaron listas!
Pero ahora teniamos que decirles a los paquetes que pasen por esas tablas, así que lo que hicimos fue usar iptables, para «encontrar» los paquetes que queriamos
encaminar por una tabla en particular, y les agregamos una marca (fwmark, que es una marca solo de uso interno).
Nos faltaba la conexion entre los paquetes marcados y nuestras tablas, por lo que usamos ip rule, para definir que los paquetes marcados, pasen por las tablas de ruteo correspondientes, y de esa manera se completo el circuito.
Bien, hemos visto un poco mas del poder del comando ip, si todo va bien seguiremos aprendiendo sobre iproute2 y la cantidad de cosas que podemos hacer con el!
Cualquier duda específica pueden dejar un comentario con su mail y me comunicaré con uds.
/* A partir de marzo nos estamos mudando a http://netsecure.com.ar o http://www.netvulcano.com.ar */
Por herencia de los ancestrales unixs, linux, tiene 3 herramientas fundamentales para la configuración de las redes:
ifconfig, route y arp.
Sin embargo, estos comandos, no nos pueden proveer de todo el potencial que el kernel linux puede darnos para nuestras redes.
He tratado de exponer en los artículos sobre Netfilet, la punta del iceberg de lo que Linux puede hacer en cuanto al manejo de paquetes de red.
IPRoute2, es el conjunto de herramientas que nos terminará de dar el control completo sobre todo ‘paquetito’ que quiera circular por nuestra red.
Adiciono una lista de los programas que instala IProute2:
Como veran, iproute no es un tema trivial, la idea de este articulo es ver el manejo BÁSICO del comando ip.
Para comenzar a ver los primeros rayos de luz, comenzaremos por la administración mas básica y cotidiana.
Repasemos el uso de ifconfig:
Onix:~# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:00:01:51:31:61 inet addr:10.6.1.1 Bcast:10.6.1.255 Mask:255.255.255.0 inet6 addr: fe80::221:86ff:fe5c:3761/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:44098 errors:0 dropped:0 overruns:0 frame:0 TX packets:27090 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:16877090 (16.0 MiB) TX bytes:6276440 (5.9 MiB) Memory:fe000000-fe020000
Ejecutando ifconfig con una interfaz como argumento nos muestra cierta cantidad de información, generalmente mas que suficiente para las tareas diarias.
Generalmente usaremos ifconfig, para configuar la dirección IP (direccion ip y mascara de de sub red), tambien para saber justamente cual es la dirección configurada, o bien para activar o desactivar una interfaz (up / down). Otra tarea, es la de crear interfaces virtuales o alias (ifconfig eth1:1 192.168.0.1).
Veamos como traducir esto a iproute, y luego explicamos como funciona!
Primeramente, iproute es un paquete que contiene 2 herramientas fundamentales ip y tc. En este momento nos centraremos en el comando ip que al igual que iptables, es una interfaz para el manejo que hace el kernel.
Basta de alaraca!
Lo que ante haciamos con un ‘ifconfig -a’ (mostrar la info de todas las interfaces), ahora podremos hacerlo con:
Onix:~# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:00:01:51:31:61 brd ff:ff:ff:ff:ff:ff inet 10.6.1.1/24 brd 10.6.1.255 scope global eth1 inet6 fe80::221:86ff:fe5c:3761/64 scope link valid_lft forever preferred_lft forever
Probablemente te tire algo parecido, pero lo primero a recalcar, es que la información básica que encontrábamos en el comando ancestral, también la encontraremos aquí. Nos estamos refiriendo a la dirección ip (dirección y mascara), pero antes de ahondar, hagamos unos ejemplos mas.
Lo que antes haciamos con ‘ifconfig eth1’.. adivinen…
Onix:~# ip addr show eth1
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
link/ether 00:00:01:51:31:61 brd ff:ff:ff:ff:ff:ff
inet 10.6.1.1/24 brd 10.6.1.255 scope global eth1
inet6 fe80::221:8
6ff:fe5c:3761/64 scope link
valid_lft forever preferred_lft forever
Eso es simple.. sigamos.
Lo que antes haciamos con ‘ifconfig eth1:1 10.0.0.1’ (un alias, o una interfaz virtual) ahora lo haríamos:
Onix:~# ip addr add 10.0.0.1 dev eth1 && ip addr show eth1 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:00:01:51:31:61 brd ff:ff:ff:ff:ff:ff inet 10.6.1.1/24 brd 10.6.1.255 scope global eth1 inet 10.0.0.1/32 scope global eth1 inet6 fe80::221:8 6ff:fe5c:3761/64 scope link valid_lft forever preferred
Vemos que se agrego una linea ‘inet 10.0.0.1/32 scope global eth1’, que si hacemos un ifconfig, es como si ni existiera.
Hasta ahi con el ifconfig, veamos como cambia el tema de las rutas.
‘route’, es un comando simple de usar, pero suficientemente potente para las tareas mas comunes, pero, no explota de forma completa lo que Linux puede hacer por nosotros.
Si antes haciamos ‘route -n’, ahora podemos hacer:
Onix:~# ip route list 10.1.1.0/24 dev eth1 proto kernel scope link src 10.1.1.1 default via 10.1.1.100 dev eth1
La informacion es casi la misma…
Bien ya vimos suficiente como para darnos cuenta que el comando ip centraliza las tareas, y trabaja de una forma distinta a la acostumbrada en los sistemas unix, sin embargo esto se adecua más a los sistemas embebidos, como por ejemplo los sistemas CISCO.
Ahora, ya dejemos las recetas prácticas y veamos un poco de teoria.
Primero, vamos a convencernos de que iproute2 no solo provee una nueva sintaxis, si no que tiene verdaderos beneficios.
Para varios, les sera de interés, saber que iproute provee la posibilidad de hacer balanceo de carga, es decir, dividir la cantidad de tráfico en distintas conexiones.
Otro de los beneficios, es poder tener varias tablas de routeo, para configurar redes complejas, y algo de lo que se habla mucho en este tiempo, que es la posibilidad de usar QoS para limitar el ancho de banda de las conexiones.
Si comparamos esto, con las arcaicas herramientas, veremos que iproute2 es una herramienta poderosa.
Revisemos entonces la forma de trabajar de iproute2, en particular, del comando ip.
El comando ip, concibe a todo como un objeto, al cuál le cambiará ciertas cualidades de dicho objeto.
Por lo cuál su sintaxis es la siguiente:
ip [ opciones ] Objeto [ Comando [ argumentos ]]
Los objetos son los siguientes (extraido de wikipedia):
Veamos el ‘objeto’ mas común: address
Desde aquí se administraran las direcciones del protocolo IP (v4 o v6) asignadas a los dispositivos (interfaces).
Como ya se mencionó cada dispositivo debe tener como mínimo una dirección, lo que significa que podrá tener mas de una también.
A diferencia de ‘ifconfig’, no se llama ‘alias’ a las direcciones agregadas, si no que iproute llama dirección primaria (a la dirección principal) y direcciones secundarias (a lo que llamabamos alias).
Address, también abreviado como ‘addr’, tiene los siguientes comandos:
‘add’, ‘del’, ‘show’, ‘flush’, ‘change’, y ‘replace’.
No son dificil de imaginar para que sirven cada uno, pero veremos algunos ejemplos.
Add:
Agrega una dirección a un dispositivo.
ip route add 10.0.0.1/24 broadcast 10.0.0.255 dev eth1
Como verán, no implica mucha complejidad.
Vimos en su sintaxis, que ‘route’ era el objeto, y ‘add’ es un comando.
Los argumentos usados para este comando, fueron:
10.0.0.1/24 : Dirección IPv4 en notación CDIR.
broadcast 10.0.0.255 : Dirección de broadcast
dev eth1 : Nombre del dispositivo
Existen otros argumentos opcionales para el comando add, y se pueden ver haciendo, como siempre.. un man ip
Del:
Borra una dirección de un dispositivo.
ip address del 10.0.0.1/24 dev eth1
El comando del, necesita que le mencionen el dispositivo al cual se le quiere borrar una dirección, y la dirección que se quiere borrar, que si no se mencionara, se borraría la primera.
Show:
Lista las interfaces y sus direcciones, y se especifica una en particular, se lista las características de esa.
Onix:~# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:11:46:6c:34:61 brd ff:ff:ff:ff:ff:ff inet 10.1.1.1/24 brd 10.1.1.255 scope global eth1 inet6 fe80::221:86ff:fe5c:3761/64 scope link valid_lft forever preferred_lft forever
O bien podemos listar una sola usando ‘ip addr show eth1’, para mostrar solo la eth1.
El comando show, también soporta mostrar las interfaces que cumplen con una característica, por ejemplo:
ip addr show to 192.168.1.1/24
Me mostraría todas las interfaces con una dirección 192.168.1.1.
Algunas de las características que se pueden usar son:
dev: Nombre del dispositivo.
scope: Dispositivos que coincidan con ese ‘scope’ (ámbito)
to: Dispositivos que contengan la ip dada.
label: ‘etiqueta’ del dispositivo
Y aquí paramos un segundito, ya que es valido aclarar, que cuando agregamos una dirección secundaria, podemos asignarle una etiqueta.
Pensemos que cuando hacemos un ‘ifconfig eth1:1 192.168.1.11’, en realidad lo que hacemos es asignarle una dirección más a la interfaz eth1, la cual llamamos eth1:1 para identificarla de forma diferente. Con ‘ip’, podemos agregar una dirección, de forma lisa y llana, o bien, asignandole una etiqueta, la cual debe coincidir en las primeras letras con el nombre del dispositivo. Por ejemplo, una dirección secundaria a eth1, podria tener un ‘label’ que se llame eth1secu o bien eth1:1.
Flush:
Se darán cuenta que hace un flush (borrado, lavado) de las direcciones de una interfaz.
ip addr flush eth1
Con lo que eth1 quedaria sin ninguna dirección IP
Bien, con esto, solo hemos visto apenas como usar el comando ip, para manejar direcciones ip.
Veamos ahora un poquito acerca de las rutas.
Otro ‘objeto’ muy usado es ‘route’, desde el cual se puede controlar de forma avanzada el sistema de router del kernel. Para finalizar este pequeño articulo sobre iproute, veamos el manejo básico y estaremos en condiciones para el proximo artículo, de hablar de cosas un poco mas ‘avanzadas’.
Con ‘ip route’ así solito, el comando nos listará las rutas definidas. Usar ‘ip route’ es sinonimo de ‘ip route show’ ó ‘ip route list’.
Al igual que Netfilter, ‘ip’ utiliza tablas, que sirven para definir las reglas de routeo.
Cada entrada de la tabla contiene un dato clave, que es la dirección de la red/host. Cuando un paquete matchea contra esa regla/ruta, (o matchea con el TOS, veremos mas adelante), se le aplica la ruta a dicho paquete. En caso de encontrarse varias coincidencias, primero se observa la dirección de red, luego el TOS, y finalmente la preferencia)
Podemos ver, que los comandos que podemos tirar sobre este objeto son iguales a los de addres.
Flush, como es de esperar, borrará la ruta/s deseadas, o todas si no se pasan argumentos, y ya dijimos que show, ó list (también abreviado como s, sh, ó l, ls, list, nos muestra las rutas, y si lo indicamos, las rutas pertenecientes a algún criterio en particular como lo vimos con address. Se agrega un comando iteresante, que es get, el cual nos permite comprobar las rutas.
Para agregar una ruta, usamos:
ip route add 'ruta'
Donde en ‘ruta’, se definirán las distintas opciones que debe cumplir un paquete para matchear con la dicha ruta. Pero algo que no es opcional, es la dirección de la red, y justamente el destino que debe tomar los paquetes que matcheen con dicha ruta.
El uso mas común sería:
ip route add 10.0.0.0/24 via 192.168.1.2
Donde le decimos al kernel, que todo lo que quiera ir hacia la red 10.0.0.0/24, utilice de pasarela a la ip 192.168.1.2.
Para cambiar una ruta podemos usar, replace o change de la misma manera.
Y para borrar una ruta, cambiariamos el del, en lugar del add, y dejando todo lo demas igual.
Queda más por ver, pero trataremos de analizarlas de forma mas profunda en la segunda parte.
Todas las correcciones son bienvenidas! 😉
/* A partir de marzo nos estamos mudando a http://netsecure.com.ar o http://www.netvulcano.com.ar */
Antes de comenzar te recomiendo ver los post anteriores ( NetFilter / IPTables I, II, III, IV)
Finalmente podemos entrar en este tema, del cual no se suele hablar mucho, y sin embargo a mi me parece por demás útil!!
Los matches de NetFilter, convierten a este firewall en un excelente sistema de filtrado y protección para nuestro sistema, por lo que trataremos de dar una vislumbre de este amplio tema.
Mencionamos en el articulo anterior que existen una buena variedad de matchs, que nos provee netfilter, para poder precisar nuestras reglas.
Vamos a ir viendo uno por uno estos matchs para poder exprimir al maximo nuestro firewall.
Nota: Los ejemplos mostrados actualmente carecen de una explicación completa de un uso real posible, son solo un ejemplo de como usarlos en una cadena.
Para comenzar, es necesario mencionar una de las funcionalidades, que le otorgan tanto poder a NetFilter, que a diferencia de lo que imaginan que voy a decir, no es el sistema de matches, si no que (además) Netfilter posee un modulo llamado Conntrack, o Connection Tracking.
Este tal ‘conntrack’, provee herramientas, para manejar las conexiones, de una forma avanzanda..
Lo que hace, es vigilar las conexiones, darles un seguimiento y relacionarlas, para que, no solo podamos establecer reglas sobre las peticiones o respuestas (considerando los paquetes de forma individual), si no sobre los flujos de información/datos que pasan a travez de nuestro Firewall.
Para esto, a las conexiones se les asigna ‘estados’. Con este ‘etiquetamiento’ de estados, NetFilter puede ejecutar una serie de herramientas, que lo vuelven muy poderoso. Una de las facultades que adquiere, es filtrar paquetes, dependiendo de si están asociados a una conexión y el estado de la misma. Esto se podrá entender cuando veamos los distintos matchs que utilizan Connection Tracking.
(Se puede evitar que netfilter haga este seguimiento mediante la tabla raw antes vista)
Los estados de una conexión pueden ser los siguientes:
INVALID, NEW, ESTABLISHED, RELATED, SNAT, DNAT, NONE, EXPECTED, SEEN_REPLY, ASSURED, CONFIRMED.
No voy a explicarlos a todos aqui, por que haciendo una man iptables ,pueden ver una pequeña pero suficiente explicación de cada uno de los estados.
Para acentar el conocimiento sobre este modulo, podemos prácticar algo con el primer match que estudiaremos:
Este match, favorito y muy popular en los scripts de firewalls, permite tomar el estado de una conexión (sea tcp , udp, o icmp).
Primero veamos cuales son los posibles estados de una conexión a matchear:
NEW, ESTABLISHED, RELATED, e INVALID
Sus nombres son muy descriptivos, hasta para los que no saben ingles.
NEW: Se da en conexiones ‘nuevas’, en el caso de una conexión tcp, estariamos hablando del primer SYN (el que abre juego) del SYN/ACK ( la respuesta) y el ACK ( de confimación). En conexiones UDP, en realidad no hay una ‘conexión’, sin embargo por razones que exceden este articulo, se toma al primer paquete udp enviado a un puerto como NEW, y en caso del ICMP, pasa lo mismo, tomandose el primer paquete para el estado NEW (por ejemplo un ICMP ECHO REQUEST).
ESTABLISHED : Son las conexiones, que (valga la redundancia) estan ya establecidas, en TCP, hablamos de los paquetes que no sean los primeros 3, y dependiendo que quien envie el FIN/ACK los últimos paquetes necesarios para cerrar la conexión, en UDP son los paquetes que provienen del mismo puerto del que se mando un paquete en ‘estado NEW’, ICMP se considera established, miestras se espera la respuesta al mensaje enviado.
RELATED : Son los paquetes que inician una nueva conexión, pero que esta asociada a otra. Por ejemplo cuando al inicio de una conexión TCP, se le responde con un mensaje ICMP, o lo mismo para UDP, o las conexiones FTP…
INVALID : Simplemente, cuando un paquete es erroneo o no reconocido, y se toma como invalido
Una vez comprendido esto, resta ver como matchear:
[ ! ] –state : Es posible listar los estados posibles que puede tener el paquete para que sea ‘atrapado’ en la regla, por ejemplo: «NEW,ESTABLISHED» o «RELATED,INVALID», o la conbinación (y cantidad) que les paresca.
Ejemplo:
iptables -A INPUT -i eth1 -m state –state ESTABLISHED,RELATED -j ACCEPT
Esto acepta todas las conexiones que estan en estado «related» o «established» (ver arriba)
Este match, tiene en sus manos herramientas que sirven para interfacear el trabajo del módulo llamado del mismo nombre. Es decir, nos otorga cierto control sobre el Connection Tracking del Kernel. En particular, es una forma avanzada del modulo anterior (state, al que de alguna manera podemos ver como una interfaz).
Por ejemplo:
[ ! ] –ctstate : Matchea si una conexión se encuentra en uno de los estados listados como argumento a esta opción. (pe: NEW,ESTABLISHED)
[ ! ] –ctproto : Matchea si coincide el protocolo (TCP, UDP, ICMP)
Como explicamos antes, Conntrack, hace que los paquetes no se vean, como simples paquetes individuales, si no que esten relacionados cuando pertenecen a una misma conexión. Las siguientes opciones nos permiten detectar paquetes que pertenezcan a una conexión:
[ ! ] –ctorigsrc address[/mask] : Donde la ip de origen es la especificada («Address[/mask]»)
[ ! ] –ctorigdst address[/mask] : Donde la ip de destino es la especificada («Address[/mask]»)
[ ! ] –ctreplsrc address[/mask] : Donde la ip de origen que responde (reply) es la especificada (esto es casi igual a ctorigsrc)
[ ! ] –ctrepldst address[/mask] : Donde la ip de destino que responde (reply) es la especificada (casi igual a ctdstsrc)
Las demas son iguales solo que correspondientes a un puerto.
[ ! ] –ctorigsrcport port
[ ! ] –ctorigdstport port
[ ! ] –ctreplsrcport port
[ ! ] –ctrepldstport port
[ ! ] –ctstatus : Detecta los estados de una conexión, los cuales pueden ser los siguientes: NONE, EXPECTED, SEEN_REPLY, ASSURED.
[ ! ] –ctexpire : Detecta según la cantidad de segundos que le faltan a una cionexión para expirar. Es decir para que Netfilter / Conntrack la considere muerta
–ctdir : Detecta si los paquetes son «ORIGINAL» o «REPLY», si no se especifica, se considera los dos casos.
Como vemos, conntrack (el match) es una forma avanzada de state.
Ejemplo:
iptables -A INPUT -p tcp -m conntrack –ctstate ESTABLISHED, RELATED -j ACCEPT
En este ejemplo, volvemos a realizar lo que hicimos en el ejemplo anterior, solo para mostrar que es lo mismo.
iptables -A INPUT -p tcp -m conntrack –ctorigsrc 10.1.10.0/24 -j ACCEPT
Ahora, para mostrar que este modulo es mas avanzado que state, lo que hacemos es lo siguiente: Aceptamos las conexiones, que (en el módulo conntrack ) tengan la ip origen en 10.1.10.0/24
Conociendo un poco la arquitectura del protocolo IP, veremos que si no existiera el TTL los paquetes podrían dar vueltas por internet indefinidamente, o nunca llegarían.
Que es el TTL? Time to Life, tiempo de vida.
El TTL, es una propiedad de la cabezera IP, en si, es solo un número que se decrementa, cada vez que atravieza un gateway (o pasarela). Y sirve
justamente, para que un paquete, no pueda quedar andando por pasarelas, como un fantasma sin destino.
Todos los paquetes IP, son generados este contador, cuyo número máximo, puede ser 255. Al pasar por cualquier Host o pasarela, se debe decrementar en uno, este contador, y si el contador es 0 se debe eliminar este paquete.
El típico ejemplo, cuando se habla de TTL, es hablar del «traceroute», ya que lo que hace este programita, es enviar paquetes ICMP, incrementando el valor TTL, de esta manera, el primer paquete, sale con un TTL en 1, al llegar a la «puerta de enlace», esta informa que el «paquete murio en transito», así, con el mensaje de error, se obtiene la ip del primer salto y se lo informa por pantalla, el segundo lo envia con TTL dos, y muere en el siguiente host, y asi sucesivamente.
Mucho ruido y pocas noeces..
Ok, Podemos usar las siguientes opciones:
–ttl-eq : Matchea si el ttl es igual al número pasado como argumento
–ttl-gt : Matchea si el ttl es más grande que el número pasado como argumento
–ttl-lt : Matchea si el ttl es mas chico que el número pasado como argumento
Ejemplo:
iptables -A INPUT -p icmp -m ttl –ttl-lt 15 -j DROP
El TTL, es ignorado por la mayoria, sin embargo este campo del paquete ip, puede llegar a ser usado para obtener información valiosa.
En este caso, rechazando los paquetes icmp con ttl menor a 15, evitamos por ejemplo ciertos «traceroutes», lo que me inspira a escribir algún otro post sobre el asunto.
Usando este match junto a «-p tcp» o «-p udp», podemos especificar rangos de puertos, tanto de origen como de destino.
–source-ports : Lista de puertos, o rango de puertos de origen
–destination-ports : Lista de puertos, o rango de puertos de destino
–ports : Lista o rango de puertos, indistinto si es de destino o de origen.
Aclaro, que Multiport matchea si el puerto del paquete (tcp o udp) coincide con cualquiera de los puertos en la lista o rango.
Se puede anteponer «!» para especificar lo contrario. (Ej. «! –ports 3:90»)
– De ahora en mas usaré [ ! ], para indicar que vale usar el «!» para negar lo especificado –
Ejemplo:
iptables -A INPUT -p tcp -m multiport –source-ports 1:1024 -j ACCEPT
Aca, aceptamos las conexiones entrantes (tcp) que provengan de los puertos 1 al 1024. Estos puertos suelen ser solo manejados por el administrador de sistema, por lo que para que alguien puede iniciar una conexión desde esos puertos, significa que tiene acceso root (en los unix) o administrador (en los windows). Si tenemos una política restrictiva entrante (es decir -P INPUT REJECT), estaríamos aceptando conexiones de otros sistemas, que solo pueda ser iniciadas por un root/administrador .
Cualquiera que tenga un AP con linux, le puede ser de mucha utilidad este match, y para quienes no seguramente que también.
Deben estar imaginando, que este match les permitira filtrar mediante MAC, y estan en lo cierto,
Espero que también hallan imaginado, que este modulo solo se puede usar en las cadenas de ingresos (PREROUTING, INPUT y FORWARD) de paquetes, por que también estarán en lo cierto, lo que es completamente lógico.
[ ! ] –source-mac : Se pasa como argumento la mac, con el formato «xx:xx:xx:xx:xx:xx»
Ejemplo:
iptables -A INPUT -m mac –source-mac aa:bb:cc:dd:ee:ff -j DROP
Mas facil, imposible. Esta cadena, rechaza las conexiones desde la mac aa:bb:cc:dd:ee:ff
Existe en la cabezera IP, una serie de bits destinados a servir como flags para el servicio diferenciado, como no existe un estandar, algunos usan DSCP y otros TOS.
[ ! ] –dscp : Matchea si el valor del paquete es el indicado.
[ ! ] –dscp-class : Matchea por clase, y los valores posibles son BE, EF,AFxx o CSx.
Ejemplo:
iptables -I OUTPUT -m dcsp –dscp 16 -j REJECT
Esta cadena, reject el uso de dscp con valor 16, de un paquete saliente. Sinceramente poco usado (hasta donde la experiencia) me muestra.
Como explicaba anteriormente, TOS es una implementación para tener en cuenta el tipo de servicio.
[ ! ] –tos : Matchea si corresponde el valor de TOS
Valores posibles:
(0x10) 16 Minimize-Delay
(0x08) 8 Maximize-Throughput
(0x04) 4 Maximize-Reliability
(0x02) 2 Minimize-Cost
(0x00) 0 Normal-Service
Ejemplo:
iptables -A INPUT -m tos –tos 0x10 -j DROP
Dropeamos todo lo entrant con TOS 16. Hoy en dia TOS es usado para implementar QoS, sumamente importante para priorizar tráfico, o controlar el ancho de banda.
Este, es uno de los módulos mas interesantes!
Es que puede ayudarnos a detectar DoS, DDoS, o incluso escaneos!
Prestemos un poco de atención:
La pegada de «recent», es que genera una lista (o varias) de ips, las cuales, luego, podemos utilizar en otra regla de iptables.
Si fueramos un super administrador, hariamos que nuestro firewall nos tiere un log de todas las ip que se conectan con nosotros, y estariamos todo el tiempo, haciendo un tail de log, para ver si alguien esta intentando realizarnos un DoS, pero como nostros somos más que un super administrador ( 😛 ), dejaremos que NetFilter sea quien trabaje por nosotros. Por lo que vamos a pedirle, que todas las conexiones que ingresen al puerto 80 sean controladas.. de que forma?
Pues pediremos que solo puedan hacer 5 conexiones (nuevas) cada 10 segundos.
Primero le diremos a iptables, como queremos que se cree la lista:
iptables -A INPUT -i eth1 -p tcp –dport 80 –tcp-flags ALL SYN -m recent –set
Así solito nomas, entonces, todas las conexiones que sean tcp dirigidas al puerto 80, con solo el flag SYN activado, seran puestas en la lista.
Y ahora descartamos los paquetes que se excedan:
iptables -A INPUT -i eth1 -p tcp –dport –tcp-flags ALL SYN -m recent –update –seconds 10 –hitcount 5 -j DROP
Je… Y si todabia no entendes bien como funciona? Ok, veamos!
Cada vez que un paquete matchea contra la primer regla, pasa a listarse en un archivo /proc/net/ipt_recent/DEFAULT.
El archivo, es «DEFAULT», por que no le pusimos un nombre especifico a la lista, pero podemos usar «–name» para otorgarle un nombre particular, lo que nos permite hacer distintos tipos de listas para distintas puertos o aplicaciones, o lo que nuestra imaginación nos dicte.
Recent, anota cada ip que matchea contra la primer regla en /proc/net/ipt_recent/nombre_que_pusimos | DEFAULT, y si matchea mas de una vez, sobre escribe esa linea, anotando la cantidad de veces que lleva matcheando. Como la primer regla, no tiene objetivo, la compración sigue camino, y al matchear con la segunda regla,
recent, obtiene la orden de limpiar la lista si se cumplio los 10 segundos, y en este caso, si alguna ip, matcheo 5 veces, pasa a cumplirse la regla y se ejecuta el DROP sobre tal IP.
Luego de este articulo, vere de escribir uno que se dedique a usar herramientas para probar estas cosas.
La cabecera TCP define un flag, que programa el tamaño maximo de un segmento (paquete tcp), esto puede se útil en redes de diferente MTU, o bien en conexiones que necesiten cierto tamaño de paquetes. Este match nos permite matchear un paquete segun el MSS (Maximun Segment Size), pudiendo usar un número o un rango.
[ ! ] –mss : Valor del MSS precisado para matchear.
Ejemplo:
iptables -A OUTPUT -p tcp -m tcpmss –mss 2000:3000
Este flag de tcp es opcional y solo se puede usar en el segmento tcp que inicia la conexión (el primer SYN). Por lo que esta cadena matchea con los segmentos tcp salientes que contengan el MSS puesto entre 2000 o 3000
Estos dos módulos, Ah y ESP, sirven para quienes esten usando IPSec, y les permite leer en la cabezera ip, los valores SPI de AH o ESP.
[ ! ] –espspi : Se especifica el valor SPI
[ ! ] –ahspi : Se especifica el valor SPI
Una de las particularidades de los sistemas unix, es la forma estructurada de otorgar permisos, que se implementa a travez de los usuarios. Estos son dueños de las cosas que crean, y de los recursos asignados. Este match utiliza esa propiedad, para verificar, que socket pertenece a que usuario, y nos permite delimitar una regla segun esa carácteristica.(solo valido para cadenas OUTPUT y POSTROUTING)
[ ! ] –uid-owner : Se puede utilizar como argumento, el nombre de usuario, el numero de usuario o un rango de numeros de usuarios
[ ! ] –gid-owner : Exactamente igual que uid-owner pero con nombres y numeros de grupos.
[ ! ] –socket-exists : Matchea si un paquete esta asociado con un socket.
Ejemplo:
iptables -A OUTPUT -p udp -m owner –uid-owner 1004:1007 -j REJECT
En esta cadena, rejecto los paquetes udp creados por los usuarios con id 1004 a 1007. Util por ejemplo, para denegar el trafico P2P.
Simple modulo que permite detectar paquetes de la capa de Link (Modelo OSI). Los tipos de paquetes exsitentes son unicast,broadcast o multicast.
Ejemplo:
iptables -A INPUT -m pkttype –pkt-type multicast -j REJECT
Detecta un paquete multicast y lo rejecta.
Mark, sirve para detectar paquetes marcados por el kernel (con el objetivo Mark) y solo sirve dentro del host que se maque, es decir, la «marca» no será detectada en otro host o nodo de la red, solo es una maca de uso interno, ya que verdaderamente no afecta al paquete, si no que es otorgada mediante el módulo Conntrack antes explicado. Sirve para, por ejemplo, establecer rutas segun dichas marcas. La «marca» debe ser un numero entero entre 1 y 4294967296.
Ejemplo:
iptables -A POSTROUTING -p tcp –dport 80 -m mark –mark 1233 -j LOG –log-prefix «LOADBALANCING»
Esta cadena, encuentra los segmentos tcp destinados al puerto 80, que estan siendo enrutados, y poseen una marca (numero 1233) y loguea dicha actividad. El modulo Mark, se utiliza en conjunto con IPROUTE2, el cual generalmente esta relacionado con balanceo de carga (aunque su utilidad va mas alla de eso)
Otro paquete favorito para scripts de firewalls, ya que provee la opción de limitar la cantidad de paquetes que matchean contra la regla. Esto significa que se pueden armar reglas para por ejemplo evitar DoS, o usarlo en combinación con el objetivo LOG, para generar logs de ciertas conexiones.
Limit, tiene dos parametros para matchear, el primero, es la cantidad de veces que se cumple la regla en un determinado tiempo, y el otro parametro, es la cantidad de veces que se cumplirá la regla antes de que se aplique el match.
Para poner un ejemplo, hablemos de un ataque muy común, un SYN Flood.
SYN Flood, es un ataque DoS, donde un atacante envia una gran cantidad de paquetes TCP, con el flag SYN activado. Cuando se recive un SYN, el host responde el ‘saludo’ y espera la confimación de la otra parte, pero en un ataque SYN Flood, esto no sucede, ya que el objetivo del ataque, es que el host receptor quede a la espera, y al quedar a la espera de muchas conexiónes… crush! DoS!
Como lo solucionamos? Ok, NetFilter al rescate!
iptables -A INPUT -p tcp --syn -m limit --limit 2/second --limit-burst 5 -j DROP
Esto se traduce a: Una vez que se hayan recibido una rafaga (burst) de 5 paquetes TCP con el Flag SYN activado, se comenzaran a recibir los paquetes si se reciben de a 2 por segundos, los demas se dropearan.
Interesante y simple modulo, que mide el largo de los paquetes.
Ejemplo:
iptables -A INPUT -p tcp -m length –length 64:1500 -j ACCEPT
Dejamos pasar los paquetes que solo tengan un tamaño entre 64 y 1500 bytes.
Match super útil, en particular si se convina con otros matches, permite establecer rangos ip, tanto de destino como de origen.
Ejemplo:
iptables -A INPUT -m iprange --src-range 192.168.1.1-192.168.1.14 -j DROPSimple, dropea todos los paquetes provenientes del rango 192.168.1.1 al 1.14
Helper, es un módulo, que puede resultar un tanto místico, sin embargo, si se tiene en cuenta, le trabajo que hace el módulo conntrack, resulta evidente su forma de trabajo.
El ejemplo más común, para explicar este match, es hablar de FTP, que como es sabido, utiliza dos puertos para realizar una transferencia de archivos.
En el primer puerto, generalmente el 21, se establece una sesión donde se ejecutan comandos, y si es necesario, se abre un segundo puerto (generalmente el 20), el cual sirve para la transferencia de los datos de los archivos.
Helper, entonces, serviría para reconocer, cuando una conexión hecha en el puerto 20, es hija de otra conexión, es decir esta relacionada, o creada, por otra conexión.
Entonces usando «-m helper –helper ftp-20» le diremos a NetFilter, que una conexión en el puerto 20, puede ser hija de una conexión de protocolo FTP.
ECN es par de bits dentro de la cabecera IP (v4), especificado, para el aviso de congestion de una red o host. La funcionalidad de este match, es detectar, si un paquete contiene estos bits activados
[ ! ] –ecn-tcp-cwr : Matchea si el bit Congestion Window Received esta activado
[ ! ] –ecn-tcp-ece : Detecta el ECN Echo
[ ! ] –ecn-ip-ect : Seguido de un número (entre 0 y 3) espesifica al ECN-Capable Transport
Si no entendes bien para que sirve el ECN, te puede quedar claro, pensando que IP no tiene un sistema de control de recepción de paquetes, y lo mismo pasa para udp, como en este mundo abunda la tecnodiversidad, no todos los nodos aplican esta opción y no es muy posible que te encuentres en un caso que necesites usar este modulo, pero si en algun momento lo necesitas, espero se te venga a la mente que netfilter , si esta preparado para ello.
En fin, hemos dado un vistaso a una serie de herramientas, que nos dan mucho, muchisimo control sobre todo lo que atravieza nuestro host, y hemos demostrado que NetFilter es uno de los mas completos firewalls existentes…
Aún me queda por mostrar los posibles targets y herramientas para comprobar todo este tipo de utilidades que nos da NetFilter, pero por ahora hay bastante por leer. Espero en un futuro cercano compilar todo en un solo doc.
Pero como saber mover las piezas de un tablero de ajedrez, no te convierte en un gran ajedrecista, esto es solo el comienzo……
Antes de comenzar te recomiendo ver los post anteriores ( NetFilter / IPTables I, II, III, V)
Esta entrega sobre Netfilter / Iptables, vamos a dejar atras ya a las cadenas y las tablas, para centrarnos un poco mas en los comandos para ingresar, borrar, remplazar y ordenar las reglas y la primera parte de los Matchs!
Hace tiempo venimos ‘tuneando’ nuestro firewall y estamos muy conformes, sin embargo, hay cosas que aun no sabemos hacer y quedaremos encantados cuando conozcamos como usarlas.
Para adentrarnos en el tema, tenemos que ver cual es la forma en que usamos iptables por costumbre:
iptables [ -t table ] command [ match ] [ target ]
donde
[ -t table ]: table puede ser filter, nat, mangle o raw, lo vimos en el articulo anterior
command: Indica que es lo que queremos hacer con la regla (hasta ahora usamos -A y -I para insertar las reglas en un cadena, pero se puede hacer mas que eso.
[ match ]: Son las condiciones que debe reunir un paquete para quedar ‘atrapado’ en esa regla, y por consiguiente dispararse hacia el correspondiente objetivo (target)
[ target ]: Es la definición de que es lo que haremos con los paquetes que coincidan con la regla
Como vemos hay una sola restricción en cuanto a la sintaxis de iptables, y es que ‘comando’ debe estar primero que todo o a lo sumo, después de «-t table». Si bien podemos ‘desordenar’ el orden de las opciones que estan entre paréntesis, no se recomienda, ya que es complicado de leer.
Sobre lo que incumbe a «-t table», ya podemos darnos por satisfecho, pero como podrían pensar, si las demás opciones son igual o mas profundas que el «-t table», sabremos que hay mucho por ver.
«Un camino de mil leguas, se comienza con el primer paso»
Estudiemos que se puede hacer desde «command»:
Un comando, tiene dos partes, una acción y una cadena donde se realiza la acción, y esto es muy tangible cuando miramos el siguiente comando:
iptables -t filter -A INPUT -s 192.168.0.0/24 -j ACCEPT
El comando, seria «-A INPUT», donde «-A» pide que la regla se inserte en la cadena INPUT
Si quisiéramos borrarla, de la misma forma que en muchos routers, para borrar una regla, hay que escribirla nuevamente indicando que queremos borrar esa regla.
iptables -t filter -D INPUT -s 192.168.0.0/24 -j ACCEPT
Este es un momento importante para recordar, que en NetFilter, es importantísimo el orden que ingresamos las reglas.
Por lo cual, veremos que el «-A» simplemente agrega una regla a la cadena, en el último lugar, haciendo de cada cadena un FIFO (First In, First Out, Primero ingresado Primero en salir) por así decirlo.
Y ya vimos que podemos querer insertar un regla primero que todas las demás, para lo cual usábamos «-I»
iptables -t filter -I INPUT -s 192.168.0.0/24 -j ACCEPT
Esto es casi todo lo necesario, para manejar nuestras reglas, sin embargo sería mejor tener un manejo mas ordenado de las reglas.
Pues desde iptables podemos manejar las reglas con números de identificación, y tan solo para probar que esto es cierto podemos hacer lo siguiente:
Onix:~# iptables -t filter -A INPUT -s 192.168.0.0/24 -j ACCEPT Onix:~# iptables -t filter -A INPUT -s 10.0.0.0/24 -j ACCEPT Onix:~# iptables -t filter -S INPUT -P INPUT ACCEPT -A INPUT -s 192.168.0.0/24 -j ACCEPT -A INPUT -s 10.0.0.0/24 -j ACCEPT Onix:~# iptables -D INPUT 1 #En esta linea borramos la regla numero 1 de la cadena input Onix:~# iptables -t filter -S INPUT -P INPUT ACCEPT -A INPUT -s 10.0.0.0/24 -j ACCEPT #Aqui vemos que solo quedo la segunda linea
Así mismo, con la opción «-I» podemos elegir el numero de orden donde será insertada la regla:
(continuando con el ejemplo anterior)
Onix:~# iptables -t filter -I INPUT -s 10.0.0.1 -j DROP #Insertamos la regla primero que todas Onix:~# iptables -t filter -I INPUT 2 -s 10.0.0.2 -j DROP #Insertamos en segundo lugar Onix:~# iptables -t filter -I INPUT 3 -s 10.0.0.3 -j DROP # etc.. Onix:~# iptables -S INPUT -P INPUT ACCEPT -A INPUT -s 10.0.0.1/32 -j DROP -A INPUT -s 10.0.0.2/32 -j DROP -A INPUT -s 10.0.0.3/32 -j DROP -A INPUT -s 10.0.0.0/24 -j ACCEPTPara finalizar este punto, podemos observar que existe una opción que sirve para el remplazo:
Onix:~# iptables -t filter -R INPUT 2 -s 10.0.0.5 -j DROP Onix:~# iptables -S INPUT -P INPUT ACCEPT -A INPUT -s 10.0.0.1/32 -j DROP -A INPUT -s 10.0.0.5/32 -j DROP # Aqui vemos como el reemplazo fue efectivo -A INPUT -s 10.0.0.3/32 -j DROP -A INPUT -s 10.0.0.0/24 -j ACCEPT
Bien, ya hicimos el primer paso, vamos con el segundo:
Esta es la parte mas divertida, al menos para mi.
Los matches, son las condiciones que el paquete tiene que ‘matchear’ para que el paquete
‘atrapado’ en la regla. Si bien habría mucho leña para cortar aquí, no puedo detenerme en explicar los conceptos que se deben manejar sobre los protocolos (IP, TCP, UDP, ICMP), por lo cual, lo que a estos sea
referente, me restringiré a mencionarlo solamente.Matches Genericos:
-p o –protocol : Número o nombre del protocolo, para saber el numero habrá que mirar /etc/protocols,
ya dijimos que las opciones son 4, tcp, udp, icmp y all, que involucra a los 3 anteriores. Vale usar el ! para denotar ‘lo contrario’, es decir si escrivo «! udp» quiere decir todo lo que no sea udp, osea tcp y icmp.-s o –source : Orgien IP del paquete, se puede usar una IP, una red con notacion CDIR o bien un dominio, pero, tengamos en cuenta, que lo que se carga en las reglas es el numero IP resulto a la hora de ingresar la regla, dado que seria imposible que se resuelva en cada paquete que reciva o envie la pc. Vale usar «!».
-d o –destination : Funciona de la misma manera que -s solo que matche sobre la dirección de destino.
-i o –in-interface : Verifica si el paquete ingresó por la interfaz pasad como argumento, solo sirve en las cadenas INPUT, FORWARD y PREROUTING, lo que es lógico. Vale usar «!».
-o o –out-interface : Al igual que -i pero sobre la interfaz de salida, y solo vale para OUTPUT, FORWARD y POSTROUTING. Es importante aclarar que especifica las interfaces de entrada y salida permite poner una barrera mas a un ataque spoofeado.
-f o –fragment : Cuando se fragmenta un paquete, dependiendo del protocolo, no contiene en su cabezera toda la información necesaria, para que quede atrapado en algunas reglas de NetFilter, para eso se creo este match, pero es importantisimo saber que mientras . Sin embargo, ecepto que uses la tabla raw para macthear NOTRACK, NetFilter no detectara los paquetes fragmentados.
Matches para protocolos (debe existir «-p tcp» o «-p udp» para que valga )
–sport o –source-port : Indica que puerto de origen debe tener, se puede utilizar rangos, por ejemplo son validos: 80 (puerto 80), 1:1023 (puerto desde el 1 al 1023), 1025: (desde el 1025 al 65535), :21 (desde el 0 al 21), y vale usar «!» que indicará todo lo contrario.
–dport o –destination-port : Igual que –sport (eceptuando que no maneja rangos cuando se usa «-p tcp, esto se debe hacer con otra opcion que veremos mas adelante, pero si funciona con «-p udp»).
–tcp-flags (solo con «-p tcp», requiere conocimientos de TCP ): Este match nos permite matchear paquetes con ciertas configuracioens de flags activados/desactivados.
Como funciona?
Primero que nada los flags posibles son: SYN, ACK, PSH, RST, FIN (de forma especial se puede usar ALL para indicar todas las flags, o NONE para indicar ninguna)
Para usar –tcp-flags primero se indica las flags que Netfilter revisará, y luego, se indican las flags que pretendemos esten activadas para que entren en la regla.
Ejemplo, si queremos DROPear solo los paquetes que contengan el flag SYN activado, se usaría:
iptables -A INPUT -p tcp –tcp-flags ALL SYN -j DROP, o bien
iptables -A INPUT -p tcp –tcp-flags SYN,ACK SYN -j DROP.
O si quisieramos matchear un paquete que no tenga ningun flag activado (el cual es invalido):
iptables -A INPUT -p tcp –tcp-flags ALL SYN,ACK,PSH,RST,FIN–tcp-options : Este match, busca matchea por el largo de los bits usados para ‘options’ en la cabecera TCP, aclaro que NetFilter no lee las opciones, solo matchea por el largo. Vale usar «!».
iptables -A INPUT –tcp-options 8 -j DROP, dropea todas los paquetes que tengan 8 bits usados par las opciones.Para icmp («-p icmp»)
–icmp-type : Con iptables -p icmp –help, obtenemos una lista de los tipos de paquetes icmp.
Todos estos matches, son implicitos, es decir, no hace falta indicar que se use un modulo especial, para que los matches funcionen. Existen otros matches, que deben ser cargados con la opción -m o –match.
Estos son: ttl, dscp, multiport, tos, recent, tcpmss, ah/esp, state, owner, packet type, mark, mac, limit, length, ip range, helper, ecn, conntrack.
Luego de estos, estan los modulos de extensiones que se pueden cargar con patch-o-matic….
Como les dije, vamos por el segundo paso y aún hay mucho por recorrer!Hasta el próximo! agradesco sus comentarios y acepto cualquier corrección ( de conceptos o de ortográfia 😀 )
/* A partir de marzo nos estamos mudando a http://netsecure.com.ar o http://www.netvulcano.com.ar */
Antes de comenzar te recomiendo que también visites lo siguientes posts ( NetFilter / IPTables I , II, IV, V)
El diseño de NetFilter puede parecer un poco complejo si no se tiene un conocimiento completo del manejo de las tablas, y se pierde mucho si no se sabe todas las opciones que existen, por lo que revisaremos el funcionamiento de cada tabla, para saber que y como podemos hacer cada cosa.
Ya habíamos dicho que existen 4 tablas (filter, nat, mangle y raw), filter es la mas común, y se la suele obviar cuando usamos iptables, y nat la usamos cuando teniamos que ‘enmascarar’ una conexion, lo que comunmente se llama natear (actuar como router), pero ni por asomo sule mencionarse las otras 2 tablas, de hecho, muchas personas ni saben que existen, y los que lo saben, tienen entendido que son ‘tablas de un uso especial’.
Trataremos de desmitificarlas aquí!
Filter
Esta tabla, tiene a su cargo, la responsabilidad de filtrar TODOS los paquetes que el sistema maneje.
Para su uso, existen 3 cadenas predefinidas:
INPUT: Todos los paquetes, que ingresen al host deberan atravezar esta cadena
OUTPUT: Todos los paquetes generados por el host, con destino saliente, deberan atravezarla
FORWARD: Todos los paquetes que ingresen al host con el fin de atravezarlo como pasarela (gateway) seran controlados por esta cadena.
Como veran, a esta tabla, ‘no se le escapa nada’, desde ella se puede filtrar de forma eficiente cualquier paquete, sin embargo, aveces, filtrar no es suficiente, y necesitamos ‘manipular’ los paquetes de red…
Nat
La tabla Nat, se hace responsable de manipular, configurar o reescribir las direcciones y puertos de los paquetes, antes de que los paquetes ‘entren’ y ‘salgan’ del host.
Como es esto posible?
Bueno, obviamente, esta tabla no hace magia y modifica los paquetes mientras aun están en el cable de red, si no, a lo que nos referimos, es que antes que el paquete sea filtrado por la tabla filter (FORWARD), podra manipularse desde la tabla Nat, con las siguientes cadenas.
PREROUTING: Los paquetes atraviezan esta cadena antes que tengan que atravezar la tabla local (filter) y desde aqui se pude cambiar la dirección de destino e incluso el puerto. Como ejemplo, podemos decir que si entra un paquete destinado a la ip 192.168.1.2 puerto 80, podemos redirigirlo a la ip 192.168.1.3 puerto 8080, cosa muy útil para los firewalls que hacen DMZ (conocido como Destination NAT)
OUTPUT: Figurita repetida? Si Esta es la misma cadena que en la tabla filter, solo que desde la tabla nat podremos, como ya dijimos, manipular los paquetes.
En este caso, no hablamos de paquetes que esten siendo encaminados por el host, si no los paquetes de origen local, y a estos podremos aplicarles una redireccion (cambio de direccion de orgine) al igual que en la cadena PREROUTING.
POSTROUTING: Como dice su nombre, pasado el routeo de la tabla filter, esta es la ultima cadena a atravezar, y sirve para modificar la dirección y puerto de origen.
Ejemplos? Si un paquete a atravezado el host, y se dirige hacia un host en internet, y lleva como direccion de origen (por ejemplo una privada) y queremos cambiarsela, usaremos esta cadena.
Esto es super usado, por todos los que usan ADSL y hacen NAT, ya veremos por que.
Para acentuar un poco esto del ‘NAT’ y sus cadenas observemos un poco…
#Redireccionaremos todo el trafico web a un proxy cache (Destination NAT)
iptables -t nat -A PREROUTING -s 192.168.1.0/24 -i eth0 -p tcp –dport 80 -j DNAT –to-destination 192.168.1.99:8080#Tenemos a nuestro firewall con una ip fija, y hemos habilitado el router, pero si solo habilitamos
#el routeo, los paquetes salen hacia internet con una direccion de origen de una red privada,
#por lo que cambiamos la dirección de origen antes de que salga, por nuestra dirección ip pública
iptables -t nat POSTROUTING -s 192.168.1.0/24 -o eth1 -j SNAT –to-source 200.34.43.3x
Ahora bien, en este último ejemplo, funcionaría siempre y cuando tengamos una IP estática, sin embargo, muchos (la gran mayoria) utiliza ADSL para conectarse a internet, por lo cual, si nuestra IP cambiara, esto no funcionaría. Para lo cual, NetFilter diseño un tipo de SNAT especial: MASQUERADE
iptables -t nat POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQUERADE
Masquerade, significa, que haga SNAT con la dirección ip que tenga asignada la interfaz de red, por la cual saldrá el paquete, por lo cual, si nuestra dirección de internet cambia, automaticamente los paquetes saldran con el SNAT correcto.
Mangle
Ahora si, ya entramos en un camino hacia una comprensión un poco mas importante del funcionamiento de NetFilter.
Observemos que si ejecutamos ‘iptables -t magle -L’, veremos que esta tabla parece poseer, todos las cadenas de las tablas anteriores, y asi es. Por que esta tabla, es omnipresente.
Mangle, utiliza cada una de las cadenas, para modificar ciertos parámetros antes que filter o nat lean esa cadena.
Es decir que, si un paquete ingresa para ser routeado, antes que ingrese al PREROUTING de NAT, ingresa ‘al PREROUTING’ de MANGLE, y desde alli, puede ser modificado. Lo mismo sucederá con todas las demas cadenas,
Si esto no te queda 100% claro, es entendible, pero tampoco es tan complicado si seguiste todo hasta aquí, pero si no estas seguro de tus ideas, te ofrezco un gráfico para que te quedes tranquilo.
Pero.. un ejemplo práctico?
Ok, a ver si esto te convence:
(advertencia: para entender lo que hacemos aquí deberás conocer conceptos acerca del manejo de los protocolos a vajo nivel, para lo que te recomiendo que leas los RFC correspondientes)
#Cambiamos el TOS (Type Of Service)
iptables -t mangle -A PREROUTING -s 192.168.0.1 -i eth0 –dport 1950 -j TOS –set-tos 0x10
#TCPMSS
iptables -t mangle -A FORWARD -p tcp -j TCPMSS –clamp-mss-to-pmtu
#Cambiar el TTL
iptables -t mangle -A FORWARD -d 0.0.0.0/0 -i eth0 -p tcp –dport 1234 -j TTL –ttl-set 1
#Bueno… cada uno sabe lo que hace no?
En fin hay varias opciones que podemos cambiar con la tabla mangle, pero no podemos detenernos en cada una de ellas, lo importante es ver, que desde ella se puede modificar ciertos aspectos de los paquetes de red, insisto nuevamente hay mucha info en el man de iptables.
raw
Esta es una tabla nueva, y no tiene mucha variedad de uso, pero no puedo limitarme a decir, simplemente que es ‘de un uso especial’, pero si he de recalcar, no que la mayoria de los kernels no la poseen ecepto que esten parcheados.
Esta tabla, existe para un solo objetivo: NOTRACK
Vale aclarar algo: NetFilter y el Kernel en si, tienen un control de las conexiones, por ejemplo no es lo mismo, que una conexión TCP, este en estado NEW (cuando se manda el SYN y se espera el SYN/ACK), que este en ESTABLISHED (cuando se recibe el SYN/ACK y se envia el SYN de respuesta).
Todo esto lo vigila NetFilter, tanto en tcp, como udp, e icmp, ahora, esto conlleva un gasto significativo de recursos, cuando hablamos de muchas conexiones simultaneas.
Para que NetFilter no lleve ese control, y economice recursos, quizas querramos que ciertas conexiones no las ‘vigile’, para lo cual podriamos usar esta tabla:
iptables -t raw -A PREROUTING -s 192.168.0.0/24 -j NOTRACK
El problema deveniente es que no podremos controlar las conexiones que se establescan de esta forma.
Y hasta ahora solo estamos viendo lo ‘bàsico’ de iptables, y aun queda mas de lo ‘bàsico’, por lo que no te pierdas el proximo articulo sobre este mounstruo del filtrado!
NetVulcano 