Flags del Kernel para Firewall o Tuneando el /proc

Opciones de Seguridad en el kernel de Linux (proc)

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

/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

Filtro anti-spoof

/proc/sys/net/ipv4/conf/eth0/rp_filter

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.

Ignorar pings

/proc/sys/net/ipv4/icmp_echo_ignore_all

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.

Syn Cookies

/proc/sys/net/ipv4/tcp_syncookies

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.

Paquetes Marcianos

/proc/sys/net/ipv4/conf/all/log_martians

Envia señales a syslog cuando entran paquetes de redes ilegales (cuando el kernel no sabe como rutearlas).

Paquetes Icmp Redirect

/proc/sys/net/ipv4/conf/all/accept_redirects

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.

ICMP Send_Reditect

/proc/sys/net/ipv4/conf/all/send_redirects

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.

Ip Connection Tracking

/proc/sys/net/ipv4/ip_conntrack_max ó
/proc/sys/net/ipv4/netfilter/ip_conntrack_max

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.

Source Route

/proc/sys/net/ipv4/conf/all/accept_source_route

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 Broadcasting  (protección smurf)

/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

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.

ICMP Dead Error Messages

/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

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.

IP Forward

/proc/sys/net/ipv4/ip_forward

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.

TCP FIN TimeOut

/proc/sys/net/ipv4/tcp_fin_timeout

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.

TCP KeepAlive Time

/proc/sys/net/ipv4/tcp_keepalive_time

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.

Proxy Arp

/proc/sys/net/ipv4/conf/all/proxy_arp

Con un 0 podemos deshabilitar esta funcionalidad, que no suele ser necesaria, a menos que seamos servidor de VPN, Firewall o Router que lo requiera.

Cache ARP

/proc/sys/net/ipv4/neigh/[interfaz de red]/gc_stale_time

Los 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)

Escalado de Ventana

/proc/sys/net/ipv4/tcp_window_scaling

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.

Algoritmo SACK

/proc/sys/net/ipv4/tcp_sack

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.

Rango de Puertos Locales

/proc/sys/net/ipv4/ip_local_port_range

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 de nuestros paquetes

/proc/sys/net/ipv4/ip_default_ttl

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)

Explicit Congestion Notification

/proc/sys/net/ipv4/tcp_ecn

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.

Conclusión:

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 */

Anuncios

Nftables, el sucesor de nuestro querido IPTables

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….

Packet Filter, otra gran opcion!

PF a la batalla!

Dentro del mundo Unix, hay varias formas de hacer lo mismo,
y considero yo, todo tiene su ámbito de aplicación, es decir, es poco inteligente poner Ubuntu (Desktop) como servidor, o un AIX como un Desktop.
Pues bien, si a OpenBSD nos referimos, su ámbito se acomoda muy bien entre los servidores/firewalls.

Packet Filter o pf para los amigos, es su prolijo y simple firewall.

– Como primer punto, podemos destacar, una interfaz que permite de manera simple centralizar las principales tareas.
La interfaz de usuario para manejar el firewall de OpenBSD es ‘pfctl’, desde el cual podremos habilitar / deshabilitar el firewall, cargar un archivo de configuración,
o listar las reglas según su tipo.
Para habilitar PF usamos:
#pfctl -e
para deshabilitar PF:
#pfctl  -d

Para cargar un archivo de configuración:
#pfctl -f /path/del/archivo

Para listar las reglas de filtrado:
#pfctl -sr
Para las reglas de nat:
#pfctl -sn
Y para ver las estadisticas:
#pfctl -si

Espectacular dirán, pero no me sirve de mucho todo esto, si no se como configurar las reglas (rules)!. Pues avancemos entonces!

– Como segunda característica y quizás la mas importante, es que la sintaxis es muy simple, y no por eso deja de ser potente.
Lleva mas tiempo comprender como usar el Sticky bit que el PF!
Par cargar las reglas, hay que escribirlas en un archivo y cargar el archivo como vimos un poco mas arriba.

Las reglas siguen una sentencia bien simple:

action [direction] [log] [quick] [on interface] [inet|inet6] [proto protocol] \
[from src_addr [port src_port]] [to dst_addr [port dst_port]] \
[flags tcp_flags] [state]

Donde action, puede ser pass o block, es evidente para que sirve cada uno.
Con direction especificamos si queremos matchear paquetes que entran o salen, por lo que usaremos in u out.
La opción log, hace que pf loguee los paquetes que matchean con dicho filtro.
Pasaremos por alto la opción quick por ahora, y veremos que es mas que obvio que con ‘on interface‘, podemos remplazarlo por ‘on pcn0‘ por ejemplo,
y matcheará solo los paquetes que entren o salgan (según hayamos definido en direction) sobre la interfaz definida.
Con inet6 definimos la regla para que matche paquetes sobre el IPv6,  en caso contrario (IPv4) usamos inet.
Como siempre, un buen firewall, nos permite seleccionar un mínimo de características sobre los paquetes que matchearemos, esto es:
Que protocolo es, de donde (ip y puerto) viene y a donde va (ip y puerto), y en el caso de los paquetes tcp, los flags activados.
Simplemente, entonces:

Seguido de proto escribiremos tcp, udp, icmp, icmp6 o cualquier protocolo en /etc/protocols (ej. proto tcp),
si queremos, podemos especificar la dirección de origen con from (ej. from 192.168.1.1),
adicionalmente podemos marcar de que puerto debe provenir el paquete, lo hago con port (ej. port 22),
para matchear los paquetes según a “donde va”, usamos to y port (ej. to 192.168.3.4 port 3218).

Antes de hablar de los flags tcp, quiero destacar una característica útil:
Cuando nos toca definir puertos, pf nos perfime definir rangos y comparaciones aritmeticas.

  • != (desigual)
  • < (menor que)
  • > (mas grande que)
  • <= (menor o igual)
  • >= (mayor o igual)
  • : ( rango inclusivo)

Por ejemplo (de paso repasamos):

pass in on pcn0 inet tcp from 192.168.1.1 to 192.168.1.2 port >= 1024
o bien
block out on pcn1 tcp to 10.10.10.3 port 20:30

Tcp flags:

Siendo que hoy en día, es muy común recibir escaneos remotos, es también muy común, querer filtrar dichos escaneos, los cuales llegan a ser interesante mente sofisticados en el protocolo TCP.
Anteponiendo ‘flag’, podremos especificar que flags activadas debe tener el paquete para que matchee. Se hace de la siguiente manera:
Primero ponemos las flags que buscamos que esten activas, seguidas de una barra “/”, y despúes las flags donde debe buscar, por ejemplo:
S/SA significa que busque el flag SYN activado solo entre los flags SYN y ACK. Para comprender esto, conviene que leas sobre escaneos aqui.

Aquí esta los distintos flags que se pueden usar.

  • F : FIN – Finish; end of session
  • S : SYN – Synchronize; indicates request to start session
  • R : RST – Reset; drop a connection
  • P : PUSH – Push; packet is sent immediately
  • A : ACK – Acknowledgement
  • U : URG – Urgent
  • E : ECE – Explicit Congestion Notification Echo
  • W : CWR – Congestion Window Reduced

Macros
Dentro del  archivo de configuración, se pueden definir ciertos “macros”.
Por ejemplo, si escribimos
int_ext = “pcn0”
creamos una constante.

O bien, podemos crear una lista:
puertos = “{ 21 22 23 443 }”
o bien
ip_denegadas = “{ 192.168.1.0/24, 10.0.0.1 }”

luego, para usarlas usaremos $puertos o $ip_denegadas.
Otra cosa, que resulta muy interesante, que el mismo PF nos permite el manejo de queueing ( o control de ancho de banda ), esto no lo veremos en este articulo, pero les dejo el link http://www.openbsd.org/faq/pf/queueing.html, y dicho sea de paso, este pequeño articulo es un “extracto” traducido de http://www.openbsd.org/faq/pf/index.html.

Conclusión:

PF es un potente firewall, que es muy simple de usar, y teniendo en cuenta que OpenBSD es seguramente el sistema operativo mas seguro, nos brinda un excelente entorno para transformar una pc en un firewall por excelencia.

Empirismo de Red (probar minimamente nuestro firewall ) II

Técnicas y estrategias

Usar scripts y programas de escaneo o pen test, es muy simple, sin embargo, para obtener información valiosa, es necesario saber que es lo que se esta haciendo.
En el artículo anterior llegamos a ver una técnica de ‘port scann’  muy común llamada SYN Scann. Su nombre indica justamente que se utiliza el flag SYN para escanear el/los puertos, tal cual lo hicimos en las pruebas del artículo anterior.
Esta vez repasaremos otras tecnicas de escaneo de puertos.
Vale aclarar que estas tecnicas de escaneo, se pueden realizar con nmap de manera muy simple, pero si no lo hacemos de esta manera, nunca sabremos como funcionan.

Xmas

Esta técnica consiste en enviar un paquete TCP con los flags FIN, PSH, y URG.
Para esto usamos:

Onix:~# hping -F -P -U -p 22 192.168.3.4

Demás esta decir que con -F activamos el flag FIN, -P -> PSH y -U -> URG.
Ahora bien, si la implementacion TCP del target (en este caso 192.168.3.4) es correcta, cuando nos encontremos ante un puerto abierto, no deberia responder nada, y en caso de ser un puerto cerrado responderia con un RST.

Onix:~# hping -c 5  -F -P -U -p 22  192.168.3.4
HPING 192.168.3.4 (eth1 192.168.3.4): FPU set, 40 headers + 0 data bytes

--- 192.168.3.4 hping statistic ---
5 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

En este caso tenemos un puerto 22 abierto, ya que no recibimos ningún RST.
Y por el contrario si revisamos el puerto 23, vemos que este se encuentra cerrado (recibimos un RST/ACK (RA) )

Onix:~# hping -c 5  -F -P -U -p 23 192.168.3.4
HPING 192.168.3.4 (eth1 192.168.3.4): FPU set, 40 headers + 0 data bytes
len=46 ip=192.168.3.4 ttl=64 DF id=0 sport=23 flags=RA seq=0 win=0 rtt=9.5 ms
len=46 ip=192.168.3.4 ttl=64 DF id=0 sport=23 flags=RA seq=1 win=0 rtt=0.3 ms
len=46 ip=192.168.3.4 ttl=64 DF id=0 sport=23 flags=RA seq=2 win=0 rtt=0.3 ms
len=46 ip=192.168.3.4 ttl=64 DF id=0 sport=23 flags=RA seq=3 win=0 rtt=0.6 ms
len=46 ip=192.168.3.4 ttl=64 DF id=0 sport=23 flags=RA seq=4 win=0 rtt=0.3 ms

--- 9.6.166.207 hping statistic ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.3/2.2/9.5 ms

Esta técnica tiene la ventaja de ser muy sileciosa, sin embargo, es facil de filtrar. Pero además se debe recalcar, que el hecho de que no responda, puede significar, que fue interceptado por el firewall y este lo dropeó y necesariamente de que el puerto esta abierto.
Para filtrar este tipo de escaneo, deberiamos decirle al firewall que no acepte segmentos TCP con los flags FIN,PSH,URG si no pertenece a una conexión ya existente.

NULL y FIN

Tanto NULL scan, como FIN scan utilizan el mismo concepto que Xmas, envian un paquete mal formateado, si responde un RST esta cerrado, en caso contrario, es probable que este abierto.

NULL scan, como dice su nombre envia un paquete sin flags TCP:

Onix:~# hping -c 5 -p 23 192.168.3.4
HPING 192.168.3.4 (eth1 192.168.3.4): NO FLAGS are set, 40 headers + 0 data bytes

--- 192.168.3.4 hping statistic ---
5 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Onix:~# hping -c q -p 23 192.168.3.4
HPING 192.168.3.4 (eth1 192.168.3.4): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=192.168.3.4 ttl=64 DF id=0 sport=23 flags=RA seq=0 win=0 rtt=1.2 ms

---192.168.3.4 hping statistic ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.5/1.2 ms

De la misma manera funciona con el escaneo FIN, solo que en lugar de no enviar flags, se envia solo el flag FIN.

Onix:~# hping -c 5 -F -p 23 192.168.3.4

Es importante recalcar, que el hecho de que no recibamos una respuesta, no es una garantia de que el puerto este abierto, ya que por ejemplo si usamos estos paquetes contra un host que no existe, no recibiremos respuesta!

ACK Scan

A diferencia de Xmas, FINScan, y Nullscan, ACK Scan no intenta encontrar los puertos abiertos/cerrados, si no mas bien los silenciosos y los hosts que deniegan las conecciones que comienzan con el flag SYN. No hace falta dar un ejemplo, ya que solo hay que activar el flag ACK y si no responde, es probable que ese puerto este filtrado.

Si leistes los articulo sobre iptables podras imaginar como bloquear estos escaneos, pero si todabia no caes, te doy una ayuda:
Para el Null Scan:  iptables -t nat -A PREROUTING -p tcp –tcp-flags ALL NONE -j DROP
Para el Xmass: iptables -t nat -A PREROUTING -p tcp –tcp-flags ALL FIN,PSH,URG -j DROP

Ok, esto son solo algunas de las utilidades que le podemos dar al hping, tiene mucho mas para darnos, por lo que te invito a que no te pierdas el proximo artículo.

/* A partir de marzo nos estamos mudando a http://netsecure.com.arhttp://www.netvulcano.com.ar */

Publicado en Articulos. Etiquetas: , , , , . 1 Comment »

Empirismo de red (Probar minimamente nuestro firewall) I

Probando nuestro Firewall

En realidad, comprobar si nuestra red es segura, es infinita mente mas trabajoso que comprobar que puertos abiertos tenemos. Sin embargo, cuando hablamos de una pc hogareña, comprobar los puertos de nuestro host, es importante, pero mucho, muchísimo mas importante es tener una noción de que hablamos cuando hablamos de puertos y como funcionan.
En conclusión, voy a tratar de explicar , para todos aquellos que busquen, por ejemplo, como comprobar si su firewall de iptables  esta funcionando adecuadamente, o si tal o cual puerto esta ‘abierto’ o ‘cerrado’. Ya que lo cierto, es que abundan ese tipo de consultas, así que sin mas adentre monos en el tema.

Si ya leistes un poco sobre como configurar tu red, y luego te aventuraste a hacerte un firewall, o (tristemente) a usar uno ya hecho, pero aún quieres probar si todo funciona como esperabas, esto quizas te ayude.

Probablemente, has leido repetidas veces acerca de los ‘puertos’, y pareciera, que si cerramos todos los puertos de nuestro host / server, entonces estaríamos seguros. Esto no es tan así, como dije antes, ‘cerrar’ un puerto no lo es todo en la vida, pero puede ser útil, o muy útil si razonas lo que estas haciendo.

Repasemos para aclarar:

Los sistemas informáticos, necesitan comunicarse entre si, y la red mas grande del mundo, para la comunicación es Internet. Esta esta basada en una arquitectura que es similar a la de una red, donde un ‘nodo’ de la red, se puede ‘comunicar’ con otro directamente, o saltando algunos otros nodos intermedios.
Por razones etimologícas, para el funcionamiento de la internet actual, se utiliza un protocolo llamado IP, al cual, en la mayoría de los casos, se lo acopla con el protocolo TCP, y en otros casos con UDP.
Estos protocolos, fueron construidos con la intención, de que una máquina pueda tener varias conexiones simultaneas utilizando el mismo protocolo.
Ahora bien, para diferenciar los datos pertenecientes a una conexión, con los datos de la otra conexión, se les asigno un rango de números, que el sistema debe implementar sobre los datos. Este número, es lo que nosotros conocemos como ‘puerto tcp’, ó ‘puerto udp’.
Estos protocolos (TPC y UDP), estan diseñados teniendo en cuenta, el modelo ‘cliente-servidor’, donde ‘un servidor’ es un sistema que espera, que un ‘cliente’ se contacte con el, para que le pueda brindar el servicio para el cual esta programado.
Entonces, por ejemplo, Apache, es un servidor web, programado para que cuando un cliente (firefox,chrome,netscape,opera,konqueror o el que usen) se conecte a él, este les brinde un servicio, en el caso de Apache, una pagina web.
Para continuar el ejemplo, los servidores web, por ser un standar, deben funcionar en el puerto 80.

Todo navegador (cliente web), buscará conectarse al puerto 80, para recibir las paginas web que se le soliciten.
Todo servidor web, funciona por defecto, brindando paginas en el puerto 80, por que es donde los navegadores la buscaran. ( Si lo se, parece recursivo)

Una vez que sabemos esto, el resto es simple:

Cuando un servidor esta corriendo, ‘abre’ un puerto a la espera de conexiones y una vez que ese servidor se para, entonces el puerto queda ‘cerrado’, por que no hay ningún programa esperando a recibir peticiones.

Vamos a los bifes

Existe un programa hyper-super-recontra-conocido, llamado Nmap, escaner de puertos y algo mas, con varios tipos de escaneo. Creo que es mas que suficiente decir que ejecutando nmap <direccion-ip>, hacer un escaneo básico, y nos informa los puertos tcp que tenemos a la escucha.
Esto nos da una mirada superficial y amplia del estado en que dicha ip se encuentra. Pero existen muchisimos manuales que hablan del nmap, por lo que no es la intención hablar de este programa. Si no que vamos a ir a otro programa, un poco menos conocido, pero super util:

Puerto abierto Puerto cerrado

Cuando un puerto tcp ( por ejemplo 80/TCP (web) , 25/TCP (smtp), 110/TCP (pop3)), se encuentra ‘abierto’, responde de una manera diferente que cuando se encuentra cerrado (obvio? no del todo.. ), justamente, tcp define una seria de saludos y respuesta necesarias para iniciar una conexión, que es llamada comunmente Three-way hand-shake, o “apreton de manos en 3 pasos”.
Básicamente consiste en lo siguiente:

CLIENTE ——-SYN——-> SERVIDOR
CLIENTE<—SYN/ACK—–SERVIDOR
CLIENTE——-ACK———>SERVIDOR

El cliente envia un ‘paquete’ TCP con el flag SYN activado, a lo que el servidor debe responder SYN/ACK (es decir las flags SYN y ACK activdas) si el puertos solicitado se encuentra a la escucha, y para que la conexión quede establecida, el cliente envia otro SYN, confirmando la conexión.
Por el contrario, si el puerto se encuentra cerrado, sucede lo siguiente:

CLIENTE——-SYN——>SERVIDOR
CLIENTE<–RST/ACK—SERVIDOR

Si el puerto se encuentra cerrado, el servidor, solo responde con un RST/ACK.

Hping
En www.hping.org/ encontraremos el download e info.
Hping nos permite confeccionar paquetes (tcp,udp,icmp) un poco mas personalizados, para hacer escaneos mas específicos.
Por ejemplo:

 hping -c 1 -n -1  2x0.x9.xx.4x

Enviará un (uno solo) simple ping.
Si pensas que para hacer eso, usas el ping normal y es menos historia, tenes razón, pero seguí leyendo y vas a ver que hay cosas que no podes hacer con un simple ping.

Con hping podemos enviar paquetes TCP con los flags que querramos:

hping -c 1 -n -p 80 -S http://www.google.com

En este caso, enviaremos un paquete tcp con el flag SYN activado, al puerto 80 de google.

Onix:~# hping -c 1 -n -p 80  -S www.google.com
HPING www.google.com (eth1 74.125.93.99): S set, 40 headers + 0 data bytes
len=46 ip=74.125.93.99 ttl=56 id=30167 sport=80 flags=SA seq=0 win=512 rtt=5.7 ms

--- www.google.com hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 5.7/5.7/5.7 ms

Como el puerto 80 de google se encuentra abierto (esperando conexiones) y responde con los flags SYN y ACK activados.
Esto mismo pasará con cualquier puerto que este abierto.

Con las siguiente opciones podes setear las distintas flags de un paquete TCP y podras experimentar los distintos resultados.

  -L  --setack     set TCP ack
  -F  --fin        set FIN flag
  -S  --syn        set SYN flag
  -R  --rst        set RST flag
  -P  --push       set PUSH flag
  -A  --ack        set ACK flag
  -U  --urg        set URG flag
Si lees el RFC de tcp, encontraras que tenes mucho para experimentar ahi.

Ahora, existe una funcionalidad interesante, que te va a ser util si la sabes implementar.
Supongamos que queremos escanear un rango de puertos de nuestro Host (digamos del 21 al 90 /TCP).
Podemos usar muchas lineas de hping tirando una vez a cada puerto o bien:

Onix:~# hping -n -p 21  -S 9.6.166.1
HPING 9.6.166.1 (eth1 9.6.166.1): S set, 40 headers + 0 data bytes
len=46 ip=9.6.166.1 ttl=255 id=49466 sport=21 flags=RA seq=0 win=0 rtt=1.8 ms
len=46 ip=9.6.166.1 ttl=255 id=22495 sport=21 flags=RA seq=1 win=0 rtt=1.2 ms
22: len=46 ip=9.6.166.1 ttl=255 id=18905 sport=22 flags=SA seq=2 win=4128 rtt=1.3 ms
len=46 ip=9.6.166.1 ttl=255 id=49665 sport=22 flags=SA seq=3 win=4128 rtt=2.2 ms
23: len=46 ip=9.6.166.1 ttl=255 id=9520 sport=23 flags=RA seq=4 win=0 rtt=1.4 ms
len=46 ip=9.6.166.1 ttl=255 id=45949 sport=23 flags=RA seq=5 win=0 rtt=1.2 ms
24: len=46 ip=9.6.166.1 ttl=255 id=25211 sport=24 flags=RA seq=6 win=0 rtt=1.2 ms
....

Aca hping comienza enviando paquetes TCP con el flag SYN activado al puerto 21, pero pronto es interrumpido por mi (presionando control-z) y comienza enviar los mismos paquetes pero al puerto 22 y asi susecivamente.

Si especificamos -z en lugar de cambiar el puerto ira aumentando el ttl y si usamos -Z, cuando presionemos control-z, el proceso tomará un curso normal poniendose en background.

Establecidos ya algunos conocimientos básicos… podremos ver (en el proximo articulo) algunas herramientas mas que nos da hping y otras herramientas.

/* A partir de marzo nos estamos mudando a http://netsecure.com.arhttp://www.netvulcano.com.ar */

Manual tutoria de hacking con hping

Publicado en Articulos. Etiquetas: , , , , . 6 Comments »

NetFilter / IPTables V

Matcheteando todo!

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.

La verdad de la milanesa

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:

State

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)

Conntrack

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

TTL

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.

Multiport

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 .

MAC

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

DSCP

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.

TOS

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.

Recent

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.

TCPMSS

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

AH/ESP

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

Owner

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.

Packet Type

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

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)

Limit

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.

Length

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.

Ip Range

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 DROP

Simple, dropea todos los paquetes provenientes del rango 192.168.1.1 al 1.14

Helper

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

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……

NetFilter / IPTables IV

Antes de comenzar te recomiendo ver los post anteriores ( NetFilter / IPTables I, II, III, V)

IPTables el un amigo del usuario

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!

Sentencia de muerte!

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 ACCEPT

Para 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.arhttp://www.netvulcano.com.ar */