Como regalo de navidad, luego de tanto tiempo sin escribir, por lo menos les paso un par de links interesantes.
Son de un laboratorio con similitudes al de netsecure, solo que abierto, dedicado al networking (principalmente en cisco), y muchisimo mas grande, les dejo esta lista sin desperdicio:
- IO Interior routing protocols, RIP
- 802.11
- IPv6, IPv4 Multicast, Common Ports, IO IPv4 ACL
- Subnetting, NAT, QoS, VLANS
- IS-IS
- SPT
- SCAPY, TCPDUMP, WIRESHARK Filters
- VOIP
Aunque en general en este blog nos restringimos a generar información y no a copiar y pegar, me pareció apropiado compartir esta lista de recursos vista en otro blog. Ya que amplia nuestra recomendación de frameworks para estudiar pentesting
Recursos para bajar:
Virtual Machines (VMs) o ISOs:
Recursos Online
Como aniversario del primer post de este blog, que en realidad comenzó en netvulcano.wordpress.com, quiero hacer un repaso de los temas que se trataron en los posts más visitados, los cuales en general hablan en Linux.
En el 2008, comenzamos con una serie de artículos dedicados a iptables:
NetFilter / IPTables I: Uso y principios básicos de iptables
NetFilter / IPTables II: Manejo de cadenas personalizadas
NetFilter / IPTables III: Manejo de las tablas de IPTables
NetFilter / IPTables IV: Macheo genérico de IPTables
NetFilter / IPTables V: Macheos avanzados
NetFilter / IPTables VI: Targets avanzados
Los cuales pronto espero reestructurar pronto.
Complementando estos artículos sobre securizar nuestro linux, hablamos de como configurar
mejor el kernel desde el proc: Flags del kernel para Firewall y en Uso de /proc/net/tcp6*
Culminando, por el momento con el artículo sobre como detectar trace routes con IPTables.
Atacamos también algunos fundamentos del networking,
comenzando por una explicación del uso del subnetting en Redes con subnetting y Tecnica del subnetting
Seguidamente empezamos a hablar de IPRoute:
Tutorial de IPRoute I: Manejo general de IPRoute
Tutorial de IPRoute II: Tablas de routeo – Balanceo de conexiones
E hicimios una pequeña demostración del uso de Scapy: Scapy, sólo para alqumistas
Mostramos las distintas arquitecturas de red, desde el punto de vista de la seguridad en Firewalls y Scaneos
También hablamos sobre el hacking en Cisco:
Cisco bajo fuego (CDP)
Cisco bajo fuego (SNMP) parte 1 y parte 2
También hablamos sobre temas de programación, como en Plugins en C para Nagios Core o en Jugando con NASM
Después hablamos sobre técnicas de Firewallking:
Probar un Firewall I: Uso básico de HPing
Probar un Firewall II: Técnicas de scaneo explicadas
Manual/Tutorial de HPing con ejemplos I: Técnicas de scaneo con HPing
Manual/Tutorial de HPing con ejemplos II: Explicación del Firewallking mediante el TTL
Manual/Tutorial de HPing con ejemplos III: Descubriendo el flujo de datos dentro de la red
Y para complementar estos 3 tutoriales, sacamos pequeños artículos sobre el uso de HPing:
HPing – ICMP, HPing – ICMP Redirec, HPing – SYN Flood, HPing – ICMP DDoS, HPing – Smurf Attack
En fin, hemos hablado de varios temas sobre seguridad, networking, hacking y linux, con lo que esperamos haber servido a la comunidad y esperamos poder seguir haciendoló.
Haciendo uso de los artículos escritos anteriormente sobre Netfilter/iptables ( I, II, III,IV, V, VI), me parece bien poner en práctica lo aprendido, por lo que en este caso, veremos como usar iptables para loguear los intentos de utilizar la técnica del traceroute sobre nuestro linux.
Que veremos en este artículo?:
Ingnorar el traceroute
Empecemos con lo mas común. Supongamos que alguien tiene la mala idea de explorar nuestra red, y leyó por ahi, que podía obtener información sobre nosotros haciendo un trace route. Por lo que se sienta enfrente de su LinuxBox y ejecuta un traceroute. Nos estan “scanenando” y nosotros ni nos dimos cuenta! Veamos que podemos hacer para evitar una situación tan trágica como esta:
La utilidad traceroute, utiliza paquetes UDP (3 paquetes x salto) enviados a los puertos 33434 en adelante. Es decir, envia un paquetre UDP al puerto 33434 con destino del objetivo, con un TTL de 1, seguidamente, envia otro paqueteUDP al puerto 33435 con un TTL 1 y luego otro igual pero al puerto 33436 (tambien TTL 1).
Con esos 3 paquetes muestra una estadistica similar a esta:
1 27.35.25.94 (27.35.25.94) 1.405 ms 1.681 ms 1.907 ms
Luego, enviará otros tres paquetes, pero con un ttl de 2 y a los puertos UDP 33437, 33438 y 33439. Así sucesivamente aumentando el TTL hasta que llegue al objetivo.
La regla para evitar este tipo de “Path discovery” es un poco obvia:
iptables -A INPUT -p udp –dport 33437:33524 -j DROP
Nota para geeks: En algún lugar, vi que usaban el target ”REJECT –reject-with icmp-port-unreachable”, con el fin de permitir el traceroute, pero no abrir los puertos.
El número 33524 surge de la siguiente cuenta: Por defecto, traceroute intenta con un máximo de 30 saltos. Por cada salto utiliza 3 puertos UDPs => 30×3 = 90 + 33434 = 33524 (En definitiva es un número arbritario que podemos cambiar)
Con esta simple regla, podemos lograr que el resultado de un traceroute (de un GNU/Linux) se ve algo así:
hacker@matrix:~# traceroute red-destino.com traceroute to red-destino.com (1.1.1.1), 30 hops max, 60 byte packets 1 9.9.9.9 (9.9.9.9) 1.314 ms 1.730 ms 1.967 ms 2 10.0.0.1 (10.0.0.1) 1.150 ms 1.182 ms 1.176 ms 3 20.20.20.20 (20.20.20.20) 1.927 ms 1.928 ms 2.457 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * *
Etc hasta el número 30.
Es decir, supongamos que nuestro linux, se encuentre en el salto número 4 (bien cerquita). El traceroute no obtendrá respuesta alguna de nuestra parte, por lo que la única información que puede obtener es que nuestra ip mas próxima es la 20.20.20.20. Al menos de esta manera
Ahora, supongamos que nuestro hacker, esta sentado sobre un windows…
Pues bien, en el caso del tracert, se utilizan paquetes ICMP (tipo 8 codigo 0, si.. un echo request), por lo cual, para no denegar el protocolo ICMP (impidiendo el ping) pero si denegando la posibilidad de hacernos un tracert, podemos usar esta combinación de reglas de iptables:
iptables -A INPUT -p icmp -m ttl --ttl-eq 1 -m recent --set --name icmp_tracert -j DROP iptables -A INPUT -p icmp -m recent --rcheck --name icmp_tracert -j DROP
Con estas reglas, le decimos a iptables, que cuando llegue un paquete con un TTL de 1, protocolo icmp ( podríamos especificar –icmp-type echo-request, para evitar solamente los paquetes del ping en particular ), guarde la IP en una tabla llamada icmp_tracert, además de rechazar el paquete. En la segunda regla le decimos que los paquetes icmp que provengan de cualquier ip que se encuentre en la tabla icmp_tracert, también deben ser rechazados, por lo que los paquetes subsecuentes (es decir los que vengan con TTL 2,3,4 en adelante) serán rechazados también.
Ya vimos, como prevenir los trace routes mas comunes y simples, pero si nuestro enemigo hacker fuere algún asiduo lector de este blog, sabría que puede utilizar hping para realizar un scaneo mas avanzado… Veamos como detectar este tipo de scaneos.
Ya en el segundo articulo sobre Hping (Firewall testing), hablamos de como detectar un puerto redirigido utilizando ”la técnica del traceroute” sobre un puerto en particular, pero no hablamos de como prevenir este tipo de escaneo.
Antes de adentrarnos en el uso de iptables como método de bloqueo y logueo de dicha técnica, recordemos un poco:
Cuando un paquete IP(indistintamente si sobre si lleva tcp,udp o icmp) es emitido desde el host“Origen”, es enviado con un TTL (Time To Live, ó tiempo de vida), el cual es decrementado en cada router que atravieza.
En primera instancia esto nos permite calcular que cantidad de routers atravieza el paquete antes de llegar ( si conocemos el TTL inicial), pero además nos permite ver (en la mayoria de los casos) si un puerto esta redirigido. Para obtener esta información debemos comparar el TTL inicial con el cual debemos enviar un paquete, para que este llegue, con el TTL inicial necesario para otro puerto. Si uno de los dos es mas chico, entonces, encontramos un puerto redirigido, ya que el TTL del mas chico ha sido decrementado una vez mas, por pasar por el router que lo redirecciona.
Si queremos evitar que nos scaneen utilzando el TTL de los paquetes como medio de obtener información, podemos hacer 2 cosas:
1. Detener todos los paquetes cuyos TTLs sean sospechozos
2. Al redirigir puertos desde nuestro linux, cambiar el TTL con el cual sale el paquete.
Para implementar la primer técnica usamos la siguiente combinación de reglas:
iptables -A INPUT -m ttl --ttl-eq 1 -m recent --set --name odd_ttls -j DROP iptables -A INPUT -m recent --rcheck --name odd_ttls --seconds 600 -j DROP
Con la primera regla, ponemos en la lista (y rechazamos) a todos los paquetes que vengan con un TTL de 1, luego, todos los paquetes provenientes de cualquier IP que esté en esa lista, los rechazamos por 10 minutos (600 segundos).
Nota: Cuidado, la segunda regla bloquea toda conexión entrante de cualquier IP que se encuentre en la lista.
Para implementar la segunda técnica, usamos:
iptables -t mangle -A POSTROUTING -j TTL --ttl-set 64
Con esta simple regla, cambiamos el TTL de cualquier paquete que sale de nuestro linux, incluso de los paquetes que fueran forwardeados por nuestro linux, impidiendo así el reconocimiento de puertos redirigidos.
En conclusión: utilizando sólo dos modulos de iptables (ttl y recent) podemos de manera simple evitar un firewalking que no suele ser tenido en cuenta en la mayoría de los scripts de firewalls comunes. Esperemos que sirva además como ejemplo de como utilizar algo de lo que hablamos en artículos anteriores.
No hablamos de Steve Jobs, simplmente por que escapa al ambitos de temas de este blog, sin embargo, no podiamos dejar de dar nuestro adios a Dennis Ritchie, quien sin discusión es uno de los hackers mas notables de nuestra era. Como creador del lenguaje C y colaborador en la creación de UNIX, es recordado además por su famoso libro K&R - “T
he C programming language” , del cual nace el famoso “Hola mundo”, el cual uso para ejemplificar la función printf.
Dennis debe ser uno de los hombres mas influyentes de la informática, ya que su legado es la base de muchos lenguajes de programación actuales y de los sistemas operativos (de verdad operativos). Pero todo eso uds ya lo leyeron en muchos otros blogs, por lo que simplemente me quedo con unos pensamientos:
Dennis, representa el espíritu hacker, creando un sistema operativo y un lenguaje en conjunto con Thomson, como un experimento. Por aquellos dias, Bell distribuyo UNIX con su código fuente a los universitarios interesados. Así comenzaron a reunirse en conferencias para mostrar errores y avances hechos sobre UNIX. De esas conferencias salió BSD y el resto es historia…
La influencia de las creaciones de Dennis, fue posible gracias a que en principio su trabajo fue distribuido libremente, y los hackers de su momento pudieron añadir su granito/montaña de arena. Que bueno sería hoy, que muchos mas se unieran al “espiritú hacker”…..
Adios mundo! Adios Ritchie!
Loading ...