BalckArch vs ArchStrike

Como dije en el post de Hacking sobre debian:

mi laptop no solo es una herramienta de pentesting, si no tambíen mi herramienta de estudio, mi centro multimedia, me enviroment de programación, y mi herramienta de trabajo diario ademas de mi laboratorio de experimentos.

Es decir, la distro que utilice en mi pc tiene que tener capacidad y herramientas de todo tipo, no solo de seguridad informática.

Anteriormente, adecue Debian para que cumpla, dentro de lo posible, tales fines, sin embargo, justamente en materia de Seguridad informática, eran pocas las herramientas disponibles y poco actualizadas.
Al pasarme a ArchLinux, me tope con BlackArch y ArchStrike, dos distribuciones enfocadas a la seguridad informática, compatibles con su distribución madre, Arch.

Como y cual elegir?
Repasaremos un poco sobre ArchLinux, y luego sobre las versiones live de ArchStrike y BlackArch, veremos como utilizar ambos repositorios desde una instalacion de Arch y compararemos las herramientas disponibles.

Un poco sobre ArchLinux

Como dice en su pagina, Arch es  “a lightweight and flexible Linux distribution that tries to Keep It Simple”

Una de las mayores ventajas de esta distribución, es su comunidad activa, con documentación actualizada, al igual que sus repositorios, una cantidad inmensa de software disponible,  y una flexibilidad muy grande en cuanto a la configuración.
Esta misma flexibilidad, contrae la necesidad saber bien como configurar, administrar y actualizar cada parte del sistema operativo, sin destruirlo.
Por decirlo de otra manera, con Arch, vuelve la diversión de usar linux.

Una característica muy interesante, es que se trata de una distribución Rolling Release, es decir que el sistema de desarrollo de la distribución consiste en liberar continuamente actualizaciones, sin pasar por un estadio previo de pruebas/congelamiento. Por lo que al instalar Arch, tenemos siempre la ultima versión de cada paquete.

Entre las contras que tiene Arch (Por decirlo de alguna manera, ya que en realidad no es una contra si no, una característica adrede), es que Arch no tiene un instalador. Esto que puede asustar a los principiantes, es una ventaja para el usuario avanzado, evitándole caer en la obligación de aceptar configuraciones preestablecidas en un instalador.

Sobre ArchStrike y BlackArch (live)

Ambas distribuciones vienen en versiones live, lo que nos permite bajar sus respectivas ISOs y probarlas. En el caso de ArchStrike, podemos bajar un OVA, tanto para VirtualBox como para VMware, por lo que nos facilita probarla en una maquina virtual.

Menu

En el caso de BlackArch tiene un menu personalizado desde donde se puede acceder a todas las herramientas instaladas. Al igual que en Kali (una de las distros mas difundidas en materia de Pentesting) si la aplicacion/herramienta es de consola (como lo son la mayoria de las herramientas disponibles) abre una consola (xterm) ejecutando el comando sin argumentos.
A diferencia en ArchStrike, el menu no contiene un acceso a todas las aplicaciones, si no solo a las aplicaciones de interfaz graficas (algunas de linea de comando, pero no abre una terminal, por lo que no sirve para nada). Por otro lado, ArchStrike tiene otras herramientas orientadas a la configuracion del sistema y el escritorio que BlackArch no tiene (mas alla de la configuracion basica de fluxbox)

Estetica

Ambas vienen con Windows Managers livianos, en el caso de ArchStrike, OpenBox y Fluxbox por defecto para BlackArch, pero en esta ultima puede elegirse otros WMs, todos ellos livianos y con exactamente la misma estetica.blackarchlogin Esta seleccion de administradores de ventanas, ayuda a concentrarnos en el pentesting y no en otra cosa. Sin embargo, ArchStrike esta mas orientada a proveer una experiencia mas amigable. Por ejemplo, viene por defecto con wicd (un administrador de redes), un applet para mostrar la bateria (en caso de las laptops) y un menu que facilita el acceso a las herramientas de configuracion del sistema, como dije anteriormente.

Instalacion (live)

Ambas vienen con un script para instalar desde la version live, sin embargo solo ArchStrike tiene un acceso directo desde el menu principal. En el caso de BlackArch, hay que iniciarlo desde una terminal con el comando blackarch-install
archstrike

Repositorios

Mas alla del uso que podemos hacer de cada listro desde sus versiones live, podemos utillizar los repositorios de ambas distribuciones, como repositorios de una PC on Arch ya instalado.

BlackArch porvee un script que instala el repositorio y la base de datos de firmas correspondientes. Con estos pasos, quedan a disposicion nuestra las herramientas para ser instaladas:

curl -O https://blackarch.org/strap.sh
sha1sum strap.sh   #El resultado deberia ser  86eb4efb68918dbfdd1e22862a48fda20a8145ff
./strap.sh #Como root o con sudo

Luego de esto, podemos listar los paquetes disponibles de la siguiente manera:

pacman -Sgg | grep blackarch | cut -d' ' -f2 | sort -u

Estas instrucciones pueden leerlas en ingles en el siguiente guia en PDF

En el caso de ArchStrike, tenemos que adicionar un repositorio en el archivo de configuracion de Arch:

cat << EOF >> /etc/pacman.conf
[archstrike]
Server = https://mirror.archstrike.org/$arch/$repo
EOF

Seguido, actualizamos la base de datos de paquetes:

pacman -Syy

Para instalar la base de firmas, debes seguir los pasos indicados en la pagina oficial.

Coexistencia de repositorios: En este momento tengo configurados ambos repositorios y no he tenido problemas.

Herramientas disponibles

Un dato importante a la hora de comparar estas distribuciones es los paquetes disponibles, por lo que me tome el trabajo de hacer un recuento de los paquetes y sus respectivas versiones, transcribo a continuacion los pasos que seguí, por si les interesa repetirlos:
Primero hice una comparacion cuantitativa de los repositorios:

pacman -Sl | awk '/blackarch/ { print $2,$3 }' > /tmp/blackarch
pacman -Sl | awk '/archstrike/ { print $2,$3 }' > /tmp/archstrike
wc -l /tmp/blackarch /tmp/archstrike 
 2145 /tmp/blackarch
 1288 /tmp/archstrike

Como vemos, BalckArch tiene mayor cantidad de paquetes, sin embargo, esto no me dice mucho, ya que no se si los paquetes que tiene disponibles, son utiles, o desactualizados, o no me interesan.
Por lo que genere un archivo que compare ambos repositorios paquete por paquete, con su respectiva version:

cat /tmp/blackarch | sort > /tmp/blackarch.sorted
cat /tmp/archstrike | sort > /tmp/archstrike.sorted
cat /tmp/blackarch.sorted /tmp/archstrike.sorted  | awk '{ print $1 }' | sort -u > /tmp/allpkgs
join -a 1   archstrike.sorted blackarch.sorted
join -a 1 allpkgs archstrike.sorted > allvsstrike
join -a 1 allpkgs blackarch.sorted > allvsblack
join  -a 1 allvsblack allvsstrike  > black-strike.compared
cat black-strike.compared | tr ' ' ';'  > black-strike.compared.csv

De esta manera obtuve un CSV con todos los paquetes y sus respectivas versiones.
Les dejo a dispocision el CSV (black-strike-compared) y una planilla de calculo (black-strike-compared) que generé a partir del mismo.

Se puede ver con estos resultados, que BlackArch, tiene mas paquetes y en general estan mas actualizados. De hecho no hay paquetes que ArchStrike tenga y BlackArch no.

Conclusiones
Ambas distribuciones tienen su puntos fuertes, sin embargo, me pesa bastante la cantidad superior de paquetes que posee BlackArch, dado que si vamos a utilizar una de esta distribuciones, la estetica será algo que configuraremos por nosotros mismo, al igual que los menus. Por otro lado, BlackArch viene, en su version live, con varios Windows Managers interesantes, como Awesome, Fluxbox e i3, lo que le da un toque mas geek.
A su vez, ArchStrike es quizas una distro que puede abrirse camino en los menos experimentados, ya que provee una experiencia mas amigable.
En particular uso ambos repositorios en una instalacion de Arch ya existente, pero en linea general eh instalado los paquetes desde los repositorios de BlackArch.

Quizas haya algun dato que se me este pasando por alto, pero hasta donde yo puedo ver, mi recomendacion se inclina por BlackArch.

Espero les haya servido la comparación y espero sus comentarios!

~have fun

 

Podcasts de Seguridad!

Les comparto una selección de podcast activos y muy buenos que he estado escuchando últimamente:

SANS Internet Storm Center Daily Network Security Podcast_logo
Este podcast es breve y sale sin falta todos los dias, ideal para actualizarte durante la mañana

Brakeing Down Security podcast
Este podcast tiene muy buen nivel de los temas tratados, es un poco mas largo, una hora al menos y sale regularmente todas las semanas

Paul’s Security Weekly
Este podcast esta estrenando una emisión semanal dedicado a la seguridad en las empresas, mientras continua con su acostumbrada y famosa periodicidad.

Down the Security Rabbithole
De periodicidad menos frecuente, pero constante, trata temas no tan técnicos en si pero muy interesantes a todo lo referente con la seguridad informática.

Defensive Security Podcast
Otro excelente podcast con temas relacionados con la seguridad informatica, de duración larga pero interesante.

Crimen Digital
Este podcast se especializa sobre todo en la parte forense de la seguridad informática. Lo mejor que escuche en español

Otros dos mas, sobre los que no tengo mucho para decir:
Security Advisor Alliance Podcast
Data Driven Security

‘Políticas y Acciones de Ciberdefensa del Ministerio de Defensa’ en #SegurInfoArgentina2015

Una de las charlas a las que elegí asistir en la jornada SegurInfo Argentina 2015, fue la que dieron:
Sergio Rossi , Jefe de Gabinete del Ministerio de Defensa
César Daniel Cicerchia, Comando Conjunto de Ciberdefensa
Fernando CorvalanAsesor Jefatura de Gabinete , Ministerio de Defensa
Oscar NissAsesor Jefatura de Gabinete, Ministerio de Defensa

En esta charla, se expuso las acciones del gobierno en materia de seguridad informática, comparto con uds las anotaciones que hice:segurinfo-cert

El gobierno en pro de una mayor soberanía digital y de aumentar la seguridad en el cyber espacio, comenzó en 2013 la creación de un Comando en Conjunto de CyberDefensa, junto con otras acciones aún en desarrollo, como lo es la creación del CERT.

El abordaje se comienza desde la difusión, dando charlas técnicas e informativas y se continua mediante la vinculación con universidades, camaras empresariales, y organizaciones de Investigación. Así mismo, se planea la creación de una Maestria de Cyber Defensa y un Consejo Consultivo ( entre Universidades, empresas y Consultores).

MINDEX

El ONTI (Oficina Nacional de Tecnologías de la Información), las FFAA, y el Ministerio de Defensa, estan trabajando en conjunto para poder definir políticas alineadas a los estándares mundiales y la definición de las variables a ser defendidas. Una de las acciones tomadas fue la creación de MINDEX, una distro linux ‘debian based’, creada con el fin de tener todas las herramientas necesarias para la encriptación y transmisión de datos de forma segura sin depender de ninguna empresa/corporación.
Esta distribución también cuenta con las herramientas ofimáticas necesarias para el trabajo diario de del Ministerio de defensa donde se esta implementando.

NETWORKING

Por otro lado, se esta trabajando en Firewalls y monitoreo en tiempo real del tráfico, en conjunto con tecnologías de BigData, para poder poder detectar y detener la formación de BotNets.
También se esta trabajando en la securización de las redes móviles.
Y con el fin de tenes disponibles recursos para la investigación y entramiento, se utilizarán la virtualización y la super computación como medio para dicho fin.

Mas allá de lo técnico

Para poder dar un marco legal y legislativo también se esta buscando generar leyes acordes que al mismo tiempo tengan sentido en el ámbito de las políticas, normas y estándares regionales y mundiales, sumando a esto la doctrina militar.
Se buscará obtener el Nivel 4 como mínimo en las auditorias*

Mis Conclusiones

La presentación me dejó una buena impresión de las medidas que se están intentando tomar, sobre todo la creación de un CERT. Creo somos uno de los muchos paises (o de entre todos) que tenemos como materia pendiente dar un marco legal al ‘cyberespacio’.  Sin embargo me deja abierta la duda sobre la transparencia que tendrá los controles que se aplicarán, y si estos no serán en algún (o en todo) momento utilizado para controlar y no para proteger.

*Nota del autor: ?????

Decisión administrativa | Boletin Oficial

~have fun

‘Gestión de los pibes de seguridad’ en #SegurInfo2015

Comparto algunas notas tomadas de la charla brindada por  Julio Ardita (CTO, Cybsec)Marcos Jaimovich (Subgerente de Seguridad Informatica Regional de Cencosud) Diego Hernán Layño (Responsable Seguridad de la Información, OSDE ) Fernando Bruzzese (Gerente Seguridad de la Información , Banco Supervielle)

En esta charla se planteo la temática de como abordar el liderazgo y administración de los empleados del área de seguridad informática. Julio Ardita actuo como moredador de la charla, recalcando la importancia del correcto gerenciamiento del sector de seguridad informática, explicando que los lideres de estos equipos son análogos a los DT en el fútbol.

pibessec

Las preguntas mas interesantes:

Cómo están conformados los equipos?

Jaimovich de Cencosud comento que están divididos en los siguientes grupos:

  1. Gestion de Accesos
  2. Embajadores de seguridad en cada  proyecto
  3. Gestión de las Normativas de Financiación

En particular, la gestión de acceso esta tercerizada, ya que debido a que las características del trabajo (poco desafiante, rutinario y básico) la rotación de personas en dichos perfiles es alta y creyeron conveniente delegarlo en otra empresa que tenga una mejor administración de dicha rotación.

Layño de Osde concordó con Jaimovich y comento que también tiene 3 grupos principales los cuales son:

  1. ABM
  2. Especialistas
  3. Operativo, funcional y Arquitectura

De igual manera que en Cencosud, Osde terceriza la gestión de acceso (ABM), por el mismo problema de rotación de los RRHH. Por otra parte Layño recalco que con respecto a los ‘Especialistas’, es decir aquellos perfiles especifícos, tienen una política de ‘dejarlos hacer’, es decir darles libertad para que puedan aportar su punto de vista y desarrollen o implementen según crean necesario.

Bruzzese del Banco Superville coincidió en la división de los grupos:

  1. ABM
  2. Control y Monitoreo
  3. Infraestructura

Pero a diferencia de los anteriores, dijo que no tercerizaban la gestión del acceso, ya que para apalear las condiciones negativas del tipo de trabajo (rutinario principalmente) y viendo que el ABM es ‘la vidriera’ del equipo de seguridad informática, decidieron proponer distintos desafíos a sus empleados con el fin de mantener la motivación.

Como evalúan los perfiles a la hora de la selección?

Jaimovich recalco la necesidad de responsabilidad, ser capaces de ver el ‘mapa del problema’ (generalistas), y capacidad de manejar la frustración, ya que muchas veces tienen que saber decir que no a ciertas cosas para defender la seguridad en la implementación de un projecto. Layño recalco la necesidad del trabajo en equipo en detrimento de los ‘gurues’, y la capacidad de comunicar los problemas con analogías, dada la necesidad de explicar cuestiones técnicas complejas a la cadena de mando que desconoce el tema. Bruzzese por su parte volvió a resaltar la responsabilidad y la confiabilidad necesaria por la criticidad del trabajo, y señalo como estrategia el incorporar mujeres, dado su mejor capacidad a la hora de relacionarse y comunicarse con otros sectores o con el cliente. Además diferenció a los generalistas de los técnicos especializados, ya que ambos son necesarios en determinados lugares, pero hay escasez de técnicos especializados.

Como tratan el paso de técnico a ‘jefe’?

Cencosud, comento Jaimovich, desarrolló la carrera técnica en paralelo con la gerencial, de modo que no existe sólo un camino para el desarrollo laboral (el del management) si no que el técnico puede seguir siendo técnico si así lo desea y aún así progresar laboralmente. De esta forma quienes quieren y se capacitan pueden pasar a ser jefes, pero sólo por gusto y no por necesidad. En esto coincidieron tanto Layño como Bruzzese recalcando que si se hacía se hacía por gusto.

Algunas conclusiones propias:

Me llamo la atención como tanto Cencosud. como Osde delegaron en otras empresas el ABM de sus usuarios, ya que si bien el problema de la rotación por falta de desafío es un problema muy importante, también lo es la criticidad del trabajo. En este caso Superville enfrentó el problema de manera más audaz y creo que tanto empleados como empresa han salido beneficiados.

Por otro lado, quiero recalcar la política de Osde de ‘dejar hacer’, la cual parece haberles dado un buen resultado. De esta manera los empleados se sienten mas útiles y la empresa recibe más productividad de sus empleados.

Finalmente un poroto más para superville que incorporó como estrategia contratar mujeres en un sector tan dominados por hombres.

~have fun

Resumen de #SegurInfoArgentina2015

El día de ayer (10 de Marzo de 2015) se realizó en Buenos Aires la Quintoagésima
primera Edición del Congreso y Feria Iberoamericana de Seguridad de la información’,
o… SegurInfo 2015…

He aquí el resumen desde el punto de vista de un Pentester independiente:

SegurInfo es un organización que se encarga de realizar eventos en distintos países latinoamericanos con el fin de divulgar conocimiento sobre seguridad informática a las empresas principalmente. El evento se orienta principalmente a CEOs, CIOs, CISOs y CTOs que deseen profundizar sus conocimientos en el área de seguridad empresarial.

segur1

La jornada fue intensa y se desarrolló en el primer y segundo piso del Sheraton (Retiro, BS AS). Las temáticas de las charlas son en general poco técnicas pero muy informativas sobre las tendencias de los peligros que corren las empresas y corporaciones en la guerra que se esta librando en estos momentos en Internet (luego escribiré sobre las charlas a las que asistí), donde la capacidad de los atacantes (cyberdelincuentes) ha sobrepasado la capacidad defensiva de las organizaciones.

Como en cada jornada de seguridad informática encontré algunas caras conocidas, y otras no tanto, ya que a diferencia de otros eventos, SegurInfo reviste, como es de esperarse, de formalidad y sus asistentes, mayormente de saco y corbata, suelen ocupar cargos gerenciales. Estos encuentran en el desarrollo del día oportunidades de contactar con empresas dedicadas a la seguridad informática y afines.

Lo recalcable:

  • Por sobre todo, el evento contó con muy buena calidad de disertantes y creo que el fin de divulgar la importancia de la seguridad informática en el sector empresarial, se cumplió muy bien.
  • Los stands de las distintas empresas patrocinadoras del evento brindaban asesoramiento, y como es de esperarse buscaban una oportunidad de negocio, pero de forma muy correcta. Por supuesto como siempre has de llevarte una lapicera de regalo, para incrementar tu coleción.
  • Varios de los stands realizaron sorteos de cámaras, tablets, pendrives, un LCD etc. Y
    avg-locker aunque no me gane nada, esto funciono como un buen incentivo para acercarse a los stands, no sólo las promotoras (merece una reflexión aparte sobre la cosificacióń)
    – 
    Una idea genial de AVG fue un locker para cargar tu celular/tablet.
  • Infaltable, la charla del Chema, aunque no demasiado útil, como siempre un poco de rizas vinieron fantásticas para distenderse y terminar el dia.
  • El evento finalizó con el sorteo de una moto, que mediante la esperanza de ganarla, aumento las ansias de ser gratificado por el valor de la entrada.

 

Lo que no me gusto:

Si bien el Sheraton es un lugar confortable, considerando el precio de la entrada, podré decir que a mi humilde parecer faltaron algunas comodidades básicas para dicho evento, a saber:

comida2
5′ luego de haber sido habilitada la mesa para comer
  • Comida: Aunque la comida fue de muy buen nivel, sólo había para el 20% de los asistentes (como mucho). Por otro lado no había lugar donde comer lo poco que había ya que escaseaban las mesas y sillas.
  • Wifi: No había wifi disponible mas que el del hotel, el cual es pago. Claramente, al no ser un evento enfocado a los técnicos, quizás pueda disminuirse su importancia. Pero por otro lado.. en que evento social/tecnológico no hay un wifi disponible?
  • Cobertura 3G: Cuento con conectividad 3G de 2 compañias y ninguna de las 2 funcionaban dentro del hotel. Algo así como si hubiera una jaula de Faraday en el lugar.
  • Breaks muy cortos y charlas atrazadas: Los descansos entre charlas fueron bastante breves y las charlas que tuvieron unos minutos de atraso se comieron los pocos que había. Aunque el evento no tiene como objetivo lo social, siempre es bueno y relajante poder tomarse un tiempo para charlar y encontrarse con gente.

Conclusiones

El evento fue de buen resultado cumpliendo con los objetivos principales y es recomendable para quienes trabajan a niveles gerenciales o dirigen una PyME o Corporación. Si sos un curioso de la informática o de la seguridad informática, el evento es recomendable si consigues un acceso gratuito.

Agradecimientos:

De forma especial quiero agradecer a Julián Reale @realejulian por ayudarme a conseguir una entrada para el evento

Charla ‘Gestion de los pibes de seguridad’
Charla ‘Politicas y acciones de ciberdefensa del Ministerio de defensa

 

~have fun

ZMap mas rápido que NMap

ZMap es un escaner de redes (tal como lo es el famosísimo nmap) que sirve para auditorias de seguridad, testings, monitoring etc etc. Sin embargo, a diferencia de otros scanners, ZMap es muy veloz y tiene un potencial muy interesante dado sus cualidades. Según sus autores, tiene la capacidad de scanear todas las ip de ipv4 en 45 minutos desde una PC normal y fue creado con el fin de encontrar vulnerabilidades en forma masiva.
Como explican en el WashintongPost:

In contrast, ZMap is “stateless,” meaning that it sends out requests and then forgets about them. Instead of keeping a list of oustanding requests, ZMap cleverly encodes identifying information in outgoing packets so that it will be able to identify responses. The lower overhead of this approach allows ZMap to send out packets more than 1,000 times faster than Nmap. So while an Internet-wide scan with Nmap takes weeks, ZMap can (with a gigabit network connection) scan the entire Internet in 44 minutes.

ZMap no tiene un registro de los paquetes enviados, simplemente envía los paquetes con data que al ser devuelta puede identificar y decodificar, haciéndolo 1300 veces mas rápido que nmap.

Instalación

Su instalación no debería serte en absoluto un problema, ya que esta portado para varias distribuciones, como se documente en su sitio:

Debian or Ubuntu: sudo apt-get install zmap
Fedora, CentOS, and RHEL: sudo yum install zmap
Gentoo: sudo emerge zmap
Mac OS (brew): brew install zmap
Arch Linux: Available through AUR

Por otro lado, lo puedes descargar/clonar desde GitHub
La información para compilarlo, puedes verla aquí

En particular, en Debian 7, necesitaras tener entre tus repositorios, los backports:

deb  http://http.debian.net/debian  wheezy-backports main contrib non-free

Uso

La rapidez de zmap hace que sea ideal para escanear una gran cantidad de hosts (syn scan) en poco tiempo (de hecho, lo hace tan rápido, que hemos de tener cuidado al usarlo). El output generado por zmap, es simple, una lista de las IPs, que pueden servir como input para otro programa. Veamos su uso más básico:

# zmap -p 22 -o iplist.txt 200.0.0.0/8

Obtendremos un output en la consola similar al siguiente:

 Mar 02 21:27:12.301 [INFO] zmap: output module: csv
0:01 1%; send: 148953 149 Kp/s (135 Kp/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hits: 0.00%
0:02 2%; send: 297811 149 Kp/s (142 Kp/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hits: 0.00%
0:03 2%; send: 446588 149 Kp/s (144 Kp/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hits: 0.00%
0:04 3%; send: 595473 149 Kp/s (145 Kp/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hits: 0.00%

Como vemos, vamos recibiendo un update del estado del escaneo en la consola a cada segundo, y en el archivo iplist.txt tendremos una lista de ips con el puerto 22.

Pero esto no es todo, hay algunas características dignas de ser recalcadas:

Control del ancho de banda:

zmap nos permite ajustar el ancho de banda que queremos utilizar con la opción -B:

zmap -B 512K -o list.txt -p 8080 83.0.0.0/8

Scan ICMP:

Podemos hacer un scan sólo utilizando ICMP con:

zmap -M icmp_echoscan -o list.txt 91.0.0.0/8

Scan UDP:

También podemos utilizar el módulo de UDP , casi con la misma velocidad que TCP, lo que es mucho:

zmap -M udp -o list.udp.txt -p 53 91.0.0.0/8

Output en JSON:

Utilizando la opción -O json podemos obtener el archivo de resultado en formato json, lo que puede ser muy útil para alguna herramienta de monitoreo o algún tipo de webservice:

zmap -O json -o list.json -p 23 15.0.0.0/16

Output en standard output:

Podemos pedirle a zmap, que la lista de IPs no las tire en el standard error con el fin de conectarlo mediante pipes a otra aplicación. Por ejemplo en la versión compilada (no la que instalamos con apt u otro gestor) tenemos un programa llamado banner-grab-tcp que sirve para obtener los banners y como sugiere el sitio de zmap podemos utilizarlo de la siguiente manera:

zmap -p 80 -N 1000 -B 10M -o - | ./banner-grab-tcp -p 80 -c 500 -d ./http-req > out 

Esta misma idea puede traspolarse a scripts hechos por nosotros mismos u otros programas que puedan recibir el input desde el standard input.

Abuso

  • A tener cuidado, zmap es una tentación a escanear grandes segmentos de red (de ips públicas).
  • Incluso si lo ejecutas en una red privada puedes llegar a generar una cantidad de tráfico indeseado que puede ser un problema para la red, por lo que mide bien los paramatros que utilizas.
  • Nunca olvides la parte ética del hacking

Extensiones

Por como si fuera poco, zmap puede ser facilmente extendido, te recomiendo le des una pasada a este link para obtener mas info de como hacerlo, verás que simple.

Conclusiones

Claramente zmap es digno de salír en las noticias (WashingtonPost article) ya que supone un gran avance y es un arma peligrosa de dos filos. Además es un proyecto muy maduro para su corta vida.
Por otro lado, me hace pensar sobre una versión de zmap para ipv6, cuya características (las de ipv6) nos hacia suponer que un escaneo masivo sería muy complejo, sin embargo esta simple herramienta nos abre un poco la cabeza. Aunque nmap tiene muchas mas cualidades, y creo yo, sigue siendo el rey de los scanners, zmap, es una herramienta que puede complementar muy bien muchas de las tareas que realizarmos en un pentesting o en auditorias internas. Definitivamente zmap no puede faltar entre tus herramientas de pentesting, hacking y auditoria. De seguro pronto la veremos en los top 10 de herramientas de hacking.

Fuentes:
Web de zmap

~have fun

Mi Spider favorito (o hacking con wget)

Wget es una herramienta conocida por todos, pero su potencial es generalmente subestimado.
Aunque quizas tengas en tu mente algo como:

 wget http://www.foo.com/varfoo.iso

Pero en realidad wget tiene mucho mas para dar.
Repasemos algunos usos y utilidades interesantes para nuestro pentesting

– Link Status
Para checkear los headers y estado de cada link del sitio:

wget -o results.txt --spider -nd -S -r -l inf www.example.com

– Busqueda de archivos
Podemos buscar archivos, para luego extraer meta data por ejemplo:

wget -r -l inf -nd -nc --ignore-case -A *.pdf www.example.com

o bien

wget -r -l inf -nd -nc --ignore-case -A jpg,gif,png www.example.com

– Guardar cookies para su estudio:

wget -r -l inf -nd -nc --save-cookies cookies.txt www.example.com

– Mirror de un sitio

wget -r -l inf -E -k -p -N http://www.example.com

– Análisis de cache:
Podemos pedirle a wget que pida al servidor http deshabilitar el cache con –no-cache. Esto simplemente hace que el servidor http nos entregue los archivos directamente, no los cacheados.

Por otro lado, a estas utilidades le sumamos las siguientes utilidades:

Especificar un ‘Referer’:
Esto le dirá al servidor http ‘desde donde accedimos al link’

--referer=http://www.google.com/search

Esta opción, en conjunto con otras, pueden ayudar a evitar que un IDS o un PDS detecten que se esta analizando el sitio.

Especificar un ‘User-Agent’:

Si no especificamos un ‘User-Agent’, wget utilizará Wget/version lo que puede ser un disparador de alarmas. Algo como esto puede ser menos sospechoso:

--user-agent='Mozilla/5.0 (compatible; MSIE 10.6; Windows NT 6.1; Trident/5.0; InfoPath.2; SLCC1; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 2.0.50727) 3gpp-gba UNTRUSTED/1.0'

En el siguiente link, hay una enorme lista de User Agents

Especificar un header:

La opción –header nos permite

Especificar los tiempos:
Otro disparador de alarma pueden ser los tiempos en que descargamos un sitio, para eso wget tiene las siguientes variables:

--wait=seconds # Especifica la cantidad de segundos entre download y download
--random-wait # Multiplica el valor de --wait por un número al azar entre 0.5 y 1.5 (Muy útil!!!)
--wait-retry=seconds # Especifica cuantos segundos esperará antes de reintentar descargar un link que ha dado error inicialmente

Una buena combinación de estos tiempos ayudará a pasar inadvertido.

Usar un archivo de input

Con -i podemos especificar un archivo donde tengamos un lista de URLs. Asimismo utilizando –force-html, el archivo de input será leído como un html. Si los links dentro del html son relativos podemos utilizar –base=url con el fin de especificar la url utilizada como base.
Por otro lado, si utilizamos ‘-i -‘ wget tomará la lista de URLs desde el standard input, lo que lo hace combinable con otros comandos utilizando un pipe.
Por ejemplo:

lynx -dump "http://www.example.com" | grep -eo "http:.*" | wget -xi -

Conclusiones

Como vemos, wget tiene opciones muy interesantes por ser una herramienta que no esta pensada originalmente para hacer pentesting. Quizas podríamos esperar  la posibilidad de especificar múltiples valores en –user-agent y –referer, pero no es nada que no se arregle un par de lineas en bash. En conclusión, has tenido wget todo este tiempo en tu consola subutilizandolo, quizás sea hora de que te des una vuelta sobre su man.

~have fun

Flags del Kernel para Firewall o Tuneando el /proc

Opciones de Seguridad en el kernel de Linux (proc)

 

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 ciertas cosas. Esta forma es, a saber, mediente variables del kernel que pueden modificarse desde 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 hay que 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

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.