Archivo de la etiqueta: Redes

Error de autenticación 802.1x mediante certificado en ISE

Deja un comentario

En un cliente hemos encontrado el siguiente problema, la autenticación de usuarios 802.1x mediante certificado falla y aparece el siguiente error en el live log de ISE:

OpenSSLErrorMessage SSL alert: code=0x22E=558 ; source=local ; type=fatal ; message=»certificate unknown.ssl/statem/statem_srvr.c:3800 error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed [error=337100934 lib=20 func=380 reason=134]»

Hay poca documentación al respecto, en este hilo de free radius se apunta a las EKU del certificado como motivo. Dado que la autenticación de máquina sí que funcionaba tras comparar los certificados y realizar varias pruebas con las propiedades de EKU, llegamos a la conclusión de que el error derivaba de que el certificado tenía marcada como crítica la clave EKU. Una vez no configurada como crítica la clave EKU la autenticación funciona perfectamente, este error también se extendía a equipos IPHONE, softphone AVAYA y posiblemente a otros dispositivos que usen las librerías de OPENSSL para la comprobación del certificado.

Convertir un certifacado pfx (Microsoft) al formato PEM con openssl

Deja un comentario
  1. openssl pkcs12 -in archivo.pfx -out resultado.pem
  2. openssl pkcs12 -nokeys -in archivo.pfx -out resultado.cert
  3. openssl pkcs12 -nocerts -in archivo.pfx -out resultado.key -nodes
  4. Si vas a usar el certificado en un Cisco CSS hay que eliminar todo el contenido delante de «—–BEGIN RSA PRIVATE KEY—–» en el archivo resultado.key

Recetas

Deja un comentario

NMAP

-Idle scan (Escaneo pasivo)

1- Obtener hosts vulnerables como intermediario

shell#: nmap -O -v -sS|sT|sA|sW|sM objetivo -oA objetivo.result

2- Buscar los hosts vulnerables en el resultado

shell#: grep «IP ID» objetivo.result.gnmap | perl -pe ‘s/Host:([^\t]+).*IP ID Seq:([^:]+)/$1 $2/’

3-Realizar ping a través de un intermediario

shell#: nmap -PN -p- -sI intermediario destino

-Escaneo ping rápido

nmap -sP rango_ip

PERL

-Sustitución en linea multlinea

perl -pi.back -e ‘undef $/; s/SEARCH/REPLACE/ims’ file

Configurar Linux como cliente web de Microsoft ISA Server o Forefront en 5 pasos

Deja un comentario

El otro día en el curro me iva fatal la conexión ADSL que utilizaba para funcionar con el único pc con Linux de la empresa (un laptop viejo que me cedieron en su día), por otro lado buscando un proxy en python para una idea que me ronda la cabeza encontré proxies que soportan la autenticación NTLM (NT Lan Manager) que es la usada por Windows y, por lo tanto, por el ISA server o Forefront, entonces se me encendió la bombilla, hice una busqueda rápida y efectivamente!! se puede validar un Linux contra un ISA server mediante un proxy que soporte NTLM, siempre y cuando el servidor de Microsoft tenga activada la opción de ser proxy web. En los repositorios de ubuntu hay varios, yo he elegido el cntlm. No es necesario añadir el pc Linux al dominio ya que conectaremos al proxy web pero ya que estamos ¿porqué no hacerlo?

Pasos a seguir

1-Añadir el pc al dominio mediante likewise-open

Como he dicho esto es OPCIONAL, y se puede obviar si no se dispone de una cuenta con suficientes privilegios para añadir elementos al Active Directory o simplemente no queremos que la máquina forme parte del mismo

  • shell#: sudo aptitude install likewise-open5
  • shell#: sudo domainjoin-cli dominio usuario_administrador_del_dominio
  • shell#: sudo /etc/init.d/likewise-open restart

Si se desea añadir el usuario del dominio a sudo hay que  editar /etc/sudoers y añadir una line del tipo DOMINIO\\usuario permisos

2- Instalar y configurar el proxy

Simplemente así

A- Instalar cntlm

shell#: sudo aptitude install cntlm

B -Editar/etc/cntlm.conf

shell#: sudo vi /etc/cntlm.conf

y establecer las variables: Username, Domain, Password, Proxy (Normalmete es ip_isa_server:8080)

C -Ejecutar

shell#: sudo cntlm -M http://abdulet.net (o cualquier url)

Default config file opened successfully
cntlm: Proxy listening on 127.0.0.1:3128
cntlm: Resolving proxy 192.168.50.37…
cntlm: Workstation name used: kubuntu
cntlm: Using proxy proxyserver:8080
Config profile  1/11… OK (HTTP code: 301)
—————————-[ Profile  0 ]——
Auth            NTLMv2
PassNTLMv2      XXXXXXXXXXXXXXXXXXXXXXX
————————————————
cntlm: Terminating with 0 active threads

D -Vomver a editar /etc/cntlm.conf, pegar el texto en rojo ¿Qué… en donde? pues donde más rabia te de 😉 y además borrar la linea del Password en texto plano

E -Reiniciar el proxy

shell#: sudo /etc/init.d/cntlm restart

F -Configurar las aplicaciones para usar el proxy 127.0.0.1 puerto 3128 (estas opciones se puede cambiar en el archivo /etc/cntlm.conf). Para configurar el proxy para las aplicaciones en general hay que editar el archivo .profile

shell#: vi .profile

, añadir estas lineas

http_proxy=»http://localhost:3128″

ftp_proxy=»ftp://localhost:3128″

y volver a iniciar sesión

Y a disfrutar la navegación!!

Demostrando la debilidad de la encriptación inalámbrica mediante WEP

Deja un comentario

Voy a demostrar la debilidad y facilidad de craquear redes wireless protegidas mediante la obsoleta encriptación WEP, paradójicamente WEP significa «privacidad equivalente a cable» (Wirede Equivalent Privacy en inglés) pero como veremos a continuación nada más lejos de la realidad. Es muy recomendable poder injectar paquetes, lo más fácil es descargar una distribución Live que se ejecute desde USB o CD por ejemplo la bactrack del equipo de remote-exploit (agradecerles su trabajo desde aquí 😉 ) estas distros además de tener aplicados todos los parches necesarios para inyectar paquetes traen todas las herramientas que vayamos a necesitar y muchas más que pueden abrir la puerta a nuevas ideas y retos (keep your mind moving…)

Herramientas que se utilizarán:

  • Kismet: Para la localización de redes
  • wirelesstools: Para la gestión de la tarjeta inalámbrica
  • aircrack-ng: Suit completa de herramientas para los ataques wireless Sigue leyendo →

Plugin routerconfigs de cacti a traves de ssh

2 respuestas

Actualmente uso cacti para recolectar datos sobre el estado de la red en el trabajo, también tenemos el Cisco Works para la administración de la misma y desde el principio lo usé para hacer copias de seguridad de las configuraciones de los dispositivos. La cuestión es que no me gusta nada el Cisco Works, creo que consume una cantidad absurda de recursos de la máquina, buscar información en los logs es una verdadera odisea y los servicios dejan de funcionar cuando les apetece, sí se pueden detectar las caidas de los servicios mediante la configuración de alertas de las tareas que ejecute, de modo que si dejas  de recibir correos sabes que ha caido el servicio de automatización de tareas: el JRN (seria algo equivalente al CRON de Unix o al planificador de tareas de Windows). Pero es que dejó de gustarme desde el principio, los que vendieron el servicio pretendias que se usase como plataforma de monitorización pero es muy poco flexible: tan solo permite el envío de alertas a una única cuenta de correo, las alerta son muy poco configurables y cuando he recibido algún correo de alerta no me ha notificado la recuperación del dispositivo. Debo decir que no he dedicado grandes esfuerzos ni tiempo a comprender este software pero la gente a la que he consultado mis dudas, que tienen certificaciones, no han sabido responder mis dudas. Así que desde el principio preferí enfocar mis esfuerzos a Nagios y posteriormente añadí Cacti obteniendo una plataforma con niveles de soporte a los que alertar diferentes criticidades en los dispositivos y tiempos de respuesta para cada nivel, algo mucho más flexible no? 🙂 además junté la capacidad de backup del Cisco Works a la de alerta de Nagios de modo que se envía la versión y la configuración del dispositivo que esté fallando junto a los datos de contacto y localización de la oficina, a eso le llamo yo un buen sistema de alertas.

Bueno ya vale de royos lo que sí tiene chulo el CiscoWorks es la capacidad de ver las diferencias entre dos versiones de las configuraciones de un dispositivo esa fué la razón de seguir usandolo para los backups, sino habría creado un servicio de Nagios que realizase la tarea, pero como ya lo realizaba un software preferí coger las configuraciones por sftp desde la máquina de Nagios… hasta que descubrí el plugin routerconfigs que también dispone de esta funcionalidad genial!. Tras instalarlo y configurarlo vi que no tenia soporte para Cisco ASA ni para CSS y que además tan solo realiza conexiones por telnet así que los dispositivos configurados para ssh no funcionan. Bueno es software libre tengo el código así que ha modificarlo. Las modificaciones que he realizado son:

  • Soporte para copiar a través de SSH
  • Mejoras en rendimiento (muy básicas, seguro que se pueden realizar más)
  • Agregado soporte para ASA y CSS
  • Integración con el sistema de logs de Cacti durante la conexión
  • Copiar el startup-config en lugar del running-config

He modificado la versión 0.1 que cuelgo aquí por si puede ser de utilidad para alguien:

para aplicar el patch una vez descargado el plugin y el patch en el mismo directorio:

tar zxf routerconfigs-0.1.tar.gz

patch -p0 < routerconfigs_0.1_ssh.patch

Espero que os sea útil 😉

Compilar madwifi para injectar paquetes con el chipset AR5008 de atheros en Ubuntu 9.04 (Jaunty)

2 respuestas

1-Pasos rápidos (Todo está explicado en detalle en el siguiente punto)

  • SO:  Ubuntu 9.04 jaunty (ejecuta el comando lsb_release -a para obtenerla)
  • Tarjeta wifi: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01) (ejecuta el comando lscpi)
  • Kernel: 2.6.28-11-generic (obtenido mediante el comando uname -a)
  • gcc del kernel: gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) (ejecuta: cat /proc/version)

Para los que tengan esta versión de ubuntu aquí dejo un paquete con el driver listo para ser usado 😉 madwifi-hal-01056-r4003_20090416-1_i386

1-Obtener los drivers de madwifi-hal de la página de snapshots del projecto madwifi

2-Obtener el parche desde esta web r3745-corregido o mediante la orden:

wget http://patches.aircrack-ng.org/madwifi-ng-r3745.patch

3-Preparar, compilar el código, cargar el módulo y probar la injección

cd src

tar zxf madwifi-hal-0.10.5.6-current.tar.gz

cd madwifi-hal-0.10.5.6-r4003-20090416/

sudo aptitude install patch

patch -p1 < ../r3745.patch-corregido

make && sudo make install

sudo modprobe -r ath9k && sudo modprobe ath_pci

sudo airmon-ng start wifi0

Found 5 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID    Name
2834    wpa_supplicant
2851    avahi-daemon
2852    avahi-daemon
5332    NetworkManager
9426    dhclient
Process with PID 9426 (dhclient) is running on interface ath0

Interface    Chipset        Driver

wifi0        Atheros        madwifi-ng
ath0        Atheros        madwifi-ng VAP (parent: wifi0)
ath1        Atheros        madwifi-ng VAP (parent: wifi0) (monitor mode enabled)

sudo aireplay-ng -9 ath1
18:25:52  Trying broadcast probe requests…
18:25:52  Injection is working!
18:25:54  Found 5 APs

Perfecto listo y funcionando 😉

Sigue leyendo →

Configurar la interfaz de gestión en un Cisco CSS

Deja un comentario

Los CSS de Cisco difieren bastante del resto de dispositivos en cuanto a comandos y configuración se refiere, mientras que en la mayoría de los dispositivos para configurar una intefaz hay que entrar en la consola de configuración y, acto seguido, entrar en la interfaz deseada para introducir los comandos que la configuran (ip address, description, vlan etc..) en los CSS no tiene absolutamente nada que ver y configuras las ipés de forma totalmente diferente. El caso que ocupa este post es configurar la interfaz de gestión. Una vez iniciada la sesión en el dispositivo hay que introducir:

CSS# config
CSS (config)# boot
CSS (config-boot)# ip address 10.54.9.8

%% System must be rebooted for IP address to take effect

CSS (config-boot)# subnet mask 255.255.255.0

%% System must be rebooted for subnet mask change to take effect

CSS (config-boot)# gateway address 10.54.9.1

Tal y como nos indica el propio CSS para que estos cambios surjan efecto es necesario reiniciar el dispositivo, así que si está en producción se debe realizar fuera del horario laboral o programar un reinicio teniendo en cuenta llegar al trabajo antes que el resto para comprobar que todo funcione como debe 🙁 gajes del oficio…

La verdad que estas divergencias en la administración de los dispositivos Cisco es algo que no acabo de asimilar y no deja de sorprenderme, se puede interpretar como una derivación de adquirir otras empresas y no acabar de pulir las cosas o quizás busque promover de esta forma la necesidad de certificarse con ellos… sea cual sea el motivo, el resultado es que dificulta la administración de una red compuesta por sus productos y da la impresión de no ser capaz de seguir una linea clara en el desarrollo de sus IOS, aunque supongo que se lo puede permitir por su posición en el mercado.

¿Como saber el CSS qué está activo?

Deja un comentario

Una de las primeras preguntas que me surgió al tratar con estos dispositivos es ¿Como qué CSS está activo? Para poder realizar esta pregunta hay que encontrarse en un escenario con dos CSS configurados para alta disponivilidad compartiendo una IP mediante HSRP claro está. Tras intentar usar el comando de los Cisco ASA «show failover» y ver que fallaba tuve que charlar sobre el tema con mi amigo Google quien, naturalmente, me mostró el camino. Una vez iniciada la sesión tan solo hay que ejecutar el comando «show virtual-routers» que produce está salida en el terminal:

CSS1# show virtual-routers

Virtual-Routers:

Interface Address: 10.30.4.5       VRID: 10
Priority:      253                     Config. Priority:  253
State:         Master                  Master IP:         10.30.4.5
State Changes: 23                      Last Change:       01/29/2009 04:59:01
Preempt:       True                    Last Fail Reason:  IF Down
Last Clearing of Stat Counters:  01/07/2009 19:04:10

Critical-Services:
CRITICAL                    State: Alive       Type: Scripted

Interface Address: 10.30.4.5       VRID: 100
Priority:      253                     Config. Priority:  253
State:         Master Master IP:         10.30.4.5
State Changes: 23                      Last Change:       01/29/2009 04:59:01
Preempt:       True                    Last Fail Reason:  IF Down
Last Clearing of Stat Counters:  01/07/2009 19:04:10

Critical-Services:
CRITICAL                    State: Alive       Type: Scripted

Interface Address: 17.16.4.13          VRID: 200
Priority:      253                     Config. Priority:  253
State:         Master Master IP:         17.16.4.13
State Changes: 2                       Last Change:       01/07/2009 19:04:15
Preempt:       True                    Last Fail Reason:  Critical Svc Down
Last Clearing of Stat Counters:  01/07/2009 19:04:10

Critical-Services:
CRITICAL                    State: Alive       Type: Scripted

La salida no será exactamente así ya que además de haber cambiado las ips se ha realizado con un solo CSS encendido, lo importante es ver que interfaz (en realidad qué IP) tiene el State en modo Master