Nuevo post en Netsecure.com.ar

Gente querida,

Pueden encontrar en http://netsecure.com.ar/2010/05/20/manual-tutorial-de-hping-con-ejemplos-i/, el primer artículo que conformará un manual lo mas completo posible de Hping y sus posibles usos, con los ejemplos necesarios, para aprender a explotarlo a full.

Espero que les guste!

Anuncios

Ruteo en Linux vs Cisco – Parte 2

Para seguir evaluando las difrencias y similitudes en ambas plataformas (ver parte 1),  trataré de ir haciendo una muestra de equivalencias en ambos sistemas, para que pueda ser usado como “diccionario” para los habitantes de estos dos mundos.

Privilegios

En el mundo de los sistemas, conozco un solo sistema operativo anarquico, es decir, donde cualquier usuario puede llegar a cambiar cualquier configuración, pero no es el tema de este artículo, si no por el contrario, tanto linux como IOS (sistema operativo de CISCO), necesitamos ciertos privilegios en el sistema para poder cambiar una configuración.
Basicamente, en linux tenemos a los usuarios, los grupos, y el usuario root.
Los permisos se otorgan mediante distintos permisos en los archivos, siendo que los archivos tienen un dueño (un usuario), tambien tienen un grupo, el cual es un conjunto de usuarios. De esta manera, linux puede distribuir ciertas responsabilidades en distintos usuarios. Sin embargo, el poder de todo lo tiene el usuario “root” (esto no es nada particular de linux, si no mas bien de los sistemas operativos unix).

Así cuando querramos configurar algo en nuestro linux deberemos tener acceso al usuario root.

Podemos pasar de usuario común a root de la siguiente manera:

usuario@myhome:~$ su - root
Password:
myhome:~#

Tipicamente, en los unix, ver el signo  # significa tener los permisos de superusuario (root).
Algo parecido (en realidad identico pero enmascarado), sucede en los sistemas IOS.
Cuando iniciamos por primera vez un router cisco, y nos conectamos mediante una terminal (hyperterminal o minicom), vemos esto:

Router>

Que significa que solo tenemos acceso a un limitado número de comandos, para poder ejecutar comandos que afecten a la configuración del router debemos ejecutar el comando “enable”.

Router>enable
Router#

Como vemos el prompt, nos muestra el signo #, que nos indica que tenemos los permisos equivalentes a root, en un sistema unix.
En este caso, ejecutar el comando enable nos transforma automaticamente en superusuarios, sin embargo, cuando se configura un router, mas que para realizar unas pruebas, se establece una contraseña, asi mismo, se puede establecer una contraseña para el usuario mas básico, de forma tal que nadie que no conozca la contraseña pueda siquiera husmear en el router.

Router>enable
Password:
Router#

Al instalar un IOS, lo primero que debemos hacer es configurar una contraseña,
para estar mas seguros de que nadie meterá las narices donde no debe.

Tanto IOS como linux, tienen mecanismos similares de autenticación, en el caso de linux pueden ser mucho mas avanzado, sin embargo no suelen tener mucha reelevancia si queremos que actue solo como router.

Guardar Cambios

Una diferencia, que si bien es simple, pero importante, es como ambos sistemas, es la forma en que estos guardan los cambios efectuados.
En ambas plataformas,  los cambios de configuración se hacen inmediatamente al ejecutar el comando, sin embargo, este cambio solo dura, hasta que se reinicie el equipo. Para perdurar los cambios mas allá de los reinicios, en las plataformas cisco, debemos ejecutar el comando “write”, este comando guarda todas los cambios realizados en el equipo, y volveran a ser levantadas una vez que se reinicie.

En linux, no existe un comando tan general que guarde todos los cambios realizados, si no que cada configuración o variable, tiene su o sus archivo/s. En las siguientes secciones revisaremos esos archivos y la forma analoga de hacerlo en cisco.

Configuración de interfaces en [ Linux | Cisco ]

Algo fundamental en cualquier dispositivo de red, es poder configurar las interfaces de red.
Compararemos los siguientes puntos, para hace un primer “approach”, en estas equivalencias entre cisco y linux.

En este post nos encargaremos de analizar y comparar estos puntos.

Configuración básica

Salvado de información

Visualización de datos


Configuración básica

Para asignara una dirección de red a una interfaz en linux (como root):

ifconfig eth0 192.168.1.1 netmask 255.255.255.0

Aún que vale recalcar que esto se mantiene por compatibilidad con los unixs, ya que la mejor manera de configurar las interfaces en linux, es con el pack de utilidades iproute2, que se haría de la siguiente manera:

ip addres add 192.168.1.1 dev eth0

Para agregar una descripción podemos agregarla en los archivos de configuración que veremos mas abajo.

En un router cisco, lo hariamos de la siguiente manera:

Router>enable
Router#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface FastEthernet 0/0
Router(config-if)#no shutdown
Router(config-if)#ip address 192.168.1.1 255.255.255.0

Al momento de ejecutar el comando enable, el router puede pedirnos un password, este password se configurar
en la instalacion del router, aunque puede quedar sin password, como en este caso.

Para agregar una descripción podemos usar:

Router(config-if)#description "Ethernet conectada a la dmz"

Para configurar el hostname de un router Cisco:
Router>enable
Router#config t
Router(config)#hostname MyRouter
MyRouter(config)#exit
MyRouter#write

El "write" graba todos los cambios hechos, por lo cual insisto en ser cuidadosos con este comando, por que si ademas de cambiar el nombre, cambiamos otra cosa, quedará grabado al ejecutar "write"
En linux, necesitamos ser root,  y lo hacemos de la siguiente manera:

gustavo@Onix:~$ su -
Contraseña:
Onix:~# hostname MyHostname
Onix:~#

Como vemos, el comando es igual que en cisco, sin embargo, pareciera ser que no cambia automáticamente el hostname,  sin embargo si es asi, solo que el hostname que vemos en nuestra consola ( Onix:~# ) es una variable que se configura en el momento que iniciamos sesión. Por lo tanto, si ejecutamos el comando exit, y volvemos a loguearnos, ya aparecerá el nombre cambiado.
Otra forma de cambiar el hostname, es ejecutando:

Onix:~# echo "MyHostname"  > /proc/sys/kernel/hostname

De todos modos, el hostname no cambiara en nuestra consola, hasta que loguemos de nuevo.
Los comandos vistos recientemente,  no cambian el hostname de nuestro linux permanentemente. Para hacerlo permanente mente, debemos editar el archivo: /etc/hostname

En este caso no necesitamos editarlo con un editor, ya que es solo una linea la que hay que cambiar:

echo "MyHostname" > /etc/hostname

Salvado de configuración de las interfaces

Tanto en Cisco, como en Linux, los cambios explicados arriba, se pierden a la hora de reiniciar el equipo. Los dos sistemas tienen formas de guardar esta información, a saber:
En una distro tipo Debian el archivo es: /etc/network/interfaces
En los sistemas tipo RedHat el archivo es: /etc/sysconfig/network-scripts/ifcfg-[nombre de la intefaz]
Para poder editar estos archivos usamos cualquier editor de texto instalado. Generalmente Vi.
Una vez editado el archivo correspondiente, los cambios no se aplican hasta que reiniciemos los scripts de red.

En la plataforma Cisco, una vez realizado el cambio pretendido, si se quiere guardar dicho cambio, se hace de la siguiente manera:

Router(config-if)#ip address 192.168.1.1 255.255.255.0
Router(config-if)#exit
Router(config)#exit
Router#write
Building configuration...
[OK]
Router#

Este comando, guarda todos los cambios realizados en el router, por lo cual hay que tener cuidado al utilizarlo, por que podemos estar guardando algun otro cambio que hayamos realizado.

Visualización de datos

En ocaciones necesitamos visualizar cierta información de las interfaces, en Cisco podemos hacerlo de la siguiente manera:

Router>show interfaces
FastEthernet0/0 is administratively down, line protocol is down (disabled)
 Hardware is Lance, address is 00e0.8f0d.d501 (bia 00e0.8f0d.d501)
 Description: "Ethernet conectada a la dmz"
 Internet address is 192.168.1.1/24
 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255
 Encapsulation ARPA, loopback not set
 ARP type: ARPA, ARP Timeout 04:00:00,
 Last input 00:00:08, output 00:00:05, output hang never
 Last clearing of "show interface" counters never
 Queueing strategy: fifo
 Output queue :0/40 (size/max)
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 0 packets input, 0 bytes, 0 no buffer
 Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
 0 input packets with dribble condition detected
 0 packets output, 0 bytes, 0 underruns
 0 output errors, 0 collisions, 1 interface resets
 0 babbles, 0 late collision, 0 deferred
 0 lost carrier, 0 no carrier
 0 output buffer failures, 0 output buffers swapped out
....

Este comando nos lista abundante información de todas las interfaces de red.

En Linux ejecutamos:

Para ver información sobre una sola interfaz:

/sbin/ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:16:17:77:cd:1b
 inet addr:192.168.1.3  Bcast:192.168.1.7  Mask:255.255.255.248
 inet6 addr: fe80::216:17ff:fe77:cd1b/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:4606 errors:0 dropped:0 overruns:0 frame:0
 TX packets:3338 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:384745 (375.7 KiB)  TX bytes:602690 (588.5 KiB)
 Interrupt:250 Base address:0x2000

Para ver info de todas las interfaces:

/sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:17:77:cd:1b
 inet addr:192.168.1.3  Bcast:192.168.1.7  Mask:255.255.255.248
 inet6 addr: fe80::216:17ff:fe77:cd1b/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:4606 errors:0 dropped:0 overruns:0 frame:0
 TX packets:3338 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:384745 (375.7 KiB)  TX bytes:602690 (588.5 KiB)
 Interrupt:250 Base address:0x2000

lo        Link encap:Local Loopback
 inet addr:127.0.0.1  Mask:255.0.0.0
 inet6 addr: ::1/128 Scope:Host
 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:4112 errors:0 dropped:0 overruns:0 frame:0
 TX packets:4112 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:176739 (172.5 KiB)  TX bytes:176739 (172.5 KiB)

Con el comando iproute, podemos visualizar sobre una sola interfaz de la siguiente manera:

ip address list eth0
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
 link/ether 00:16:17:77:cd:1a brd ff:ff:ff:ff:ff:ff

ó

ip address list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
 link/ether 00:16:17:77:cd:1b brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.3/29 brd 192.168.1.7 scope global eth0
 inet6 fe80::216:17ff:fe77:cd1b/64 scope link
 valid_lft forever preferred_lft forever

para ver la info de todas las interfaces.

En los siguientes posts veremos algunos detalles mas avanzados, relacionados con el ruteo en ambos sistemas.

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

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

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

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 »