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

Anuncios

Tecnica de subnetting, el camino de los segmentos

En otro artículo (ver) vimos como dividir redes en segmentos, pero saber contabilizar IPs, es solamente un rudimento del networking.
Hoy nos encargaremos de ver como aplicamos esta técnica de forma correcta, para poder aprovechar y los beneficios de una buena diagramación de red.

VMLS en REDES

Siempre que tengamos algo mas que un switch y un router, conviene economizar IPs.

RedVMLS

Esta red consta de 4 routers, 4 enlaces, y 3 redes.

Supongamos que esta es una red a la cual debemos administrar, y para empezar, debemos asignarle las direcciones IPs.
Comenzaremos con las redes, es decir RED1, RED2 y RED3.
A la hora de decidir que rango IP asignaremos a una red, debemos meditar en la cantidad de hosts que posee actualmente, y calcular el crecimiento.
Imaginaremos que RED1 consta de 20 hosts pertenecientes a un aula, el cual probablemente continúe casi con la misma cantidad de hosts. Por consiguiente podriamos optar por una  /27 (255.255.255.224), es decir 30 hosts.

Numeraríamos entonces, a la RED1 con 192.168.1.0/27.
Es decir podemos asignar desde 192.168.1.1 a 192.168.1.30 y nuestra dirección de broadcast sería 192.168.1.31.
En el caso de la RED2, podemos pensar que es nuestro campus, en el cual se brinda acceso wireless, el cual da acceso a unas 8 o 9 notebooks como maximo. Para lo cual nos viene excelente una /28 (255.255.255.248), que nos permite tener unas 14 IPs para asignar.
Y he aqui la diferencia entre una red bien diagramada y una que no.
Si no conocieramos la técnica de VMLS, asignariamos a cada red un rango de ip distinto, por ejemplo 192.168.1.0/24, 192.168.2.0/24 y 192.168.3.0/24, sin embargo, ahora tenemos conocimiento suficiente como para hacer las cosas un poco mas prolijas.
A la hora de numerar la RED2, ya sabemos que lo mas adecuado sería utilzar un /28 por la cantidad de host que esta red posee, pero para ser prolijos  y economizar IPs no queremos usar un rango IP distinto, sin embargo si usamos 192.168.1.0/28 estaríamos superponiéndonos a la RED1, ya que la red 192.168.1.0/28 abarca desde 192.168.1.0 a la 192.168.1.15, y eso abraca parte del rango asignado a la RED1.

Superposicion

Por consiguiente, la próxima red que podriamos asignar sería la 192.168.1.16/28, pero tambíen se superpone a parte del rango asignado a la RED1, pero si usamos el siguiente salto, es decir 192.168.1.32/28, ya estamos fuera del alcance de la RED1.
Una vez mas, al configurar la RED3, debemos calcular que rango hemos ya usado, en este ejemplo tenemos ocupadas desde 192.168.1.1 hasta la 192.168.1.47, que es la dirección broadcast de RED2. Dependiendo de la cantidad de hosts que necesite RED3, podriamos estar usando 192.168.1.48/28, o bien usar 192.168.1.48/29, o quizas si la red es grande 192.168.1.64/27, donde estariamos perdiendo 17 ips, que dado el caso podriamos calcular un rango que entre justo, y usarlo en la red que estará detras del router 4, pero en todo caso, lo dejo como un ejercicio que te servirá para ver si realmente entendistes.

Enlaces

Finalmente, a la hora de numerar las interfaces de los distintos routers que participan en los enlaces, aplicaremos la misma técnica, solo que en este caso, como es costumbre se usan las /30, que nos provee de 2 IPs para asignar, que es, ni mas ni menos que lo que necesitamos

Ejemplo:

En el enlace 1, podríamos usar el rango 192.168.2.0/30, donde tenemos 192.168.2.1 y 192.168.2.2 para asignar, y por convención asignariamos la 192.168.2.1 al router 1, y 192.168.2.2 al router 2. Obviamente al siguiente enlace, le asignaremos el proximo salto, que es 192.168.2.4/30, el cual abarca desde 192.168.1.4 (número de red) al 192.168.1.8 (dirección de broadcast), y así consecutivamente…

De esta manera, ya tenemos nuestra red, configurada con solo 2 rangos, que al mismo tiempo nos permiten seguir agregando sub redes.
Los beneficios son evidentes en cuanto a la enomización de IPs, ya que por ejemplo, en el peor de los caso de que la RED3 necesite usar un /27, perderiamos 17 ips nada mas, sin embargo, si en lugar de /27 usaramos /24, en cada una de las redes y enlaces, usariamos unos 7 rangos de ip, perdiendo 250 IPs en los enlaces y un poco menos en las distintas redes.

A medida que la red crece, se hace mas necesario saber hacer uso de esta técnica, ya que no solamente economiza IPs, si no que además, aumenta la perfomance de la red en las tablas de routeo, algo que podríamos tratar en algun post de Encaminamiento regulado.

Es así como el camino de los segmentos de red nos lleva hacia la sabiduría del networking con subnetting!

Sin mas, cualquier duda, correción o comentario serán bienvenidos!

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

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.

IProute, el gran director II

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

Tablas de Ruteo

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

Redes con subneting!

Divide y vencerás!

Esta máxima romana viene a hacerse presente de nuevo para ayudarnos a imperar sobre las redes!

Solución rápida: http://www.aprendaredes.com/cgi-bin/ipcalc/ipcalc_cgi, además, te dejo una tabla 100% útil al final del artículo.

El problema: La escases

Cuando tenemos un switch y un router, con solo algunas pcs, crear una red no es un problema,
pero si uno debe enfrentarse a una legión de pcs, con muchos routers y switches, es muy importante que conozcamos como movernos y como crear redes y subredes.
No es un problema trivial, ya que cuando se diagramo el protocolo IP, no se imaginó el crecimiento exponencial que tendría Internet, y la escases de direcciones que eso significaría. Claro que no es para culparlos, 4.294.967.296 de IPs disponibles era un número muy amplio como para pensar en que algún dia sería poco!

La solución: Subdividir

CIDR fue la respuesta a la necesidad de mayor flexibilidad a la hora de crear redes con direcciones de 32 bits (ipv4). CIDR introdujo una nueva manera de interpretar las mascaras de subred de las direcciones ip, con la técnica VLSM.

A los bifes!

Ahora bien, aún no te queda en claro nada? Bueno… demasiada intro, vayamos a los bifes!
Para explicar Subnettin/CDIR/VLSM voy a usar los clásicos ejemplos de números IP designados para redes privadas, pero lo mismo es aplicado a la hora de crear redes para ISPs/Carriers.

Si alguna vez configuraste una PCs/Server en una red, seguramente habras utilizado una dirección IP y una mascara de sub red. Quizas no tenias plena certeza de lo que la mascara de subred significa, pero si de que lo mas común es que esta, sea 255.255.255.0. Pues en configuraciones caseras raras veces veras otras mascaras.
Aclaremos un concepto entonces antes de seguir:
Una dirección IP, no es solo ese famoso número al estilo 192.168.1.2.
Una dirección IP, esta compuesto por su número IP (p.e. 192.168.1.2) y por su mascara de sub red (p.e. 255.255.255.0), ambas cualidades de una dirección ip, indicaran a que red lógica pertenece dicha dirección. Es decir que un número ip, sin su correspondiente mascara de subred, no es mas que un número!

Ejemplo:

Los números IP: 192.168.1.1, 192.168.1.2, y 192.168.1.3 que tienen como mascara de subred 255.255.255.0, pertenecen todos a la misma red.
Sin embargo el número 192.168.1.4 con mascara de subred 255.255.255.240 no pertenece a la red anterior

Expliquemos por que:

Para determinar la red a la que pertenece una dirección IP debemos dejar de pensar en decimal y pasar nuestra mente a binario (al estilo matrix! )
Repasemos binario:Como todos sabemos en binarios solo existen 2 dígitos, 1 y 0, con los cual formaremos cualquier otro número. Asi, el 0 es el 0 que conocemos en decimal, el 1 es el 1 que conocemos de decimal, pero el 2 decimal se expresa en binario de la forma 10, por eso dicen que existen solo 10 tipos de personas en el mundo las que saben binario y las que no. Mas allá del chiste, veamos una tablita:

Binario    Decimal

0                  0
1                  1
10                2
11                3
100              4
101              5
110              6

y asi sucesivamente.

De forma tal que cuando vemos el número 255, en realidad deberíamos mirar con nuestro ojo de matrix lo siguiente:  11111111
8 unos! Si ya se que no sabes ni sumar en binario, y saltamos de 6 al 255 en binario, pero no puedo extenderme mas sobre binario en este minitutorial, por lo que te doy la regla, y si tu intriga te lleva, estudiaras un poco mas en algún otro lado:

0            0            0            0            0            0            0            0
128        64          32          16          8            4            2            1

Asi de simple, cada vez que aparece un 1 en la linea de los 0, sumas el número decimal correspondiente, por ejemplo:

0            0            0            1            0            1            1            1
128        64          32          16          8            4            2            1

Entonces,  10111 es 23 en decimal (16 + 4 + 2 + 1).

Transformemos una mascara de subred:

255.255.255.0 es:

11111111.11111111.11111111.00000000

Los importantes aca, son los 1. La mascara de sub red tiene 3 octetos de unos, 3 grupos de 8 unos, y eso es 3×8=24, no?
Si, por eso habrás visto algo parecido a lo siguiente: 192.168.1.1/24, es decir, dirección Ip 192.168.1.1 con mascara 255.255.255.0, en si, una forma mas compacta de expresarlo.
Los 8 ceros nos indican la cantidad de hosts que esa red tiene, y para saberlo podemos usar: 2^X, siendo X=8 (32 – 24 = 8 ) en este caso, que es la cantidad de bits que la mascará de subred tiene “desactivados”.  2^8 es 256, y esta es la cantidad de hosts que entran en esa red, sin embargo, a estas 256 ips posibles, se le debe restar siempre 2, ya que la primera dirección posible es reservada para “nombre de red” o “unicast” y la última para “broadcast”.

Así, nuestros ojos matrixiados ya ven, que 192.168.1.1/24 indica, que la red contiene 256 ips, de las cuales la 192.168.1.0 (la primer ip) es el nombre de la red, y 192.168.1.255 es el broadcast de la red. Así mismo vemos que las IP disponibles van desde la 192.168.1.1 a la 192.168.1.254.

Pfff, cuanto lio para decir algo que sin trabajar en binario ya sabiamos…. Pero, ahora ya sabes por que es así! no es hermoso? Avancemos!

Una vez entendido lo anterior, podemos (recien) meternos con Subnetting

Como dijimos CDIR sirve para que IP tenga mas flexibilidad a la hora de crear redes, ya que hasta 1993, solo se conocian las redes con mascaras de subred /24, /16 y /8,
que son las famosas redes de clase:

Red de Clase C, por ejemplo 192.168.1.0 255.255.255.0 (256 nodos posibles)
Red de Clase B, por ejemplo 172.16.0.0 255.255.0.0     ( 65536 nodos posibles)
Red de Clase A, por ejemplo 10.0.0.0 255.0.0.0              (16777216 nodos posibles)

Cual era el problema? Simple, si teniamos una red con 300 nodos, teniamos que configurar una red del tipo B por solo unos pocos nodos, y “desperdiciabamos” 65400 y pico de nodos posibles, lo que quizas para una red privada podría no ser un problema, pero cuando hablamos de redes públicas es grave, ya que habia que distribuir las ips al rededor de todo el mundo, y con ese tipo de saltos (de 256 a 65536 por ejemplo) pronto no habría mas direcciones para asignar.
Además si bien, no parece problematico para las redes privadas, si lo es, ya que las redes lógicas disminuyen los dominios de broadcast, y por lo tanto aumentan el rendimiento de la red.

Para implementar CIDR, sólo debemos abrir nuestra mente:

11111111.11111111.11111111.11100000

Traducido es, 255.255.255.224,  o bien un  /27.
Esta mascara de subred nos brinda la posibilidad de tener un red con 32 host
Entonces, si asignamos esta mascara a una direccion como por ejemplo 192.168.1.50, tendríamos los siguientes datos:

Dirección IP: 192.168.1.50
Mascara de subred: 255.255.255.224
Cantidad de nodos disponibles: 30
Elevo 2 a la 5 (la cantidad de 0s) 2^5=32 menos 2 (unicast y broadcast), es una red de 30 nodos
Primera IP de la red: 192.168.1.33
En este ejemplo debemos considerar que hemos dividido a una red de 256 direcciones IP en redes mas pequeñas de 32 (haciendo la cuenta 256/32, 8 redes de 32 nodos)
Por lo tanto, la primera red va desde 192.168.1.0 (unicast) a 192.168.1.31(broadcast), la segunda red va desde 192.168.1.32 (unicast) a 192.168.1.63 (broadcast).
Y ahi ya vemos que nuestro hosts ( 192.168.1.50) esta en la segunda red, por lo q la primera ip disponible para asignar es la 192.168.1.33.

Bien, hasta aquí, tenes las herramientas minimas necesarias para conocer un poco mas sobre subnetting, faltaría que veas que pasa con una red con mascara 255.255.224.0, pero eso ya lo podes prácticar vos solo, por que en si, es lo mismo

A la carga! Divide y venceras!!!!!

Subnetting

Referencias:
http://www.netexpresslabs.com/info/subnet
http://es.wikipedia.org/wiki/CIDR

Para mas info, sobre la aplicación correcta de VMLS ver este artículo

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

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 »