Cisco ASA cifrados seguros Vpn anyconnect
Es recomendable escanear nuestros dominios ligados a los accesos remotos por vpn (anyconnect), esto puede ser un punto importante que se debe considerar para evitar un ataque cibernético.
(more…)
Cisco FTD: Troubleshooting S2S VPN – Verificar VPN S2S
En seguridad de redes los túneles VPN sitio-a-sitio son de los enlaces más frecuentes con los que un administrador de redes se topará. Estos tienen la capacidad de encriptar todo el trafico que pasa a través de ellos añadiendo asi una capa de seguridad extra a la comunicación. Hoy en dia se da por hecho que un equipo perimetral como los firewalls debe contar con la capacidad de establecer estos túneles sin impactar el rendimiento de sus demas funciones.
Read more: Cisco FTD: Troubleshooting S2S VPN – Verificar VPN S2SCisco Firepower Threat Defense es la nueva serie de Firewalls de siguiente generación lanzados por Cisco a partir de su adquisicion de SourceFire propietarios de los firewalls Firepower en el 2013. Desde entonces la plataforma Firepower ha ido evolucionando y desarrollandose a partir de una fucion entre los equipos de la generación pasada Cisco Adaptative Security Apliance (ASA) y los nuevos Firepower.
La función resultó en equipos con planos de control y datos administrados por el motor LINA (ASA) es decir las características de capa 1-4 son como lo fueron en los Cisco ASAs; mientras tanto, características en capa de aplicación como: IPS, IDS, URL filtering, Anti Malware etc son orquestadas por el motor SNORT de Firepower.
Con el panorama anterior nos podemos hacer una idea que el manejo de las VPN sitio a sitio recae sobre el motor LINA, es decir que si venimos de administrar Cisco ASA podremos correr y verificar VPN S2S en Firepower tal como si lo hicieramos en ASA. En la siguiente lista podremos encontrar los comandos básicos para la verificación y el troubleshooting de VPN sitio a sitio en Cisco Firepower:
Verificar Security Associations – Fase 1
>system support diagnostic-cli
FTD#show crypto isakmp sa
En este ejemplo podemos ver 2 túneles Sitio a Sitio, 1 IKEV1 y 1 IKEV2, hemos ocultado la informacion sensible de la salida del comando, pero podemos apreciar para la sección de IKEv1 la cantidad de Security Associations creados (Active SA), el estado en el que se encuentra (MM_ACTIVE), el role del equipo (initiator). Para el caso de IKEv2 nos muestra el estado de la sesión 56 (Session-id 56), el tipo de encriptación del túnel, el estado (UP-ACTIVE), la cantidad de tunnel selector creados para este caso 2 (CHILD count) y el role del equipo (RESPONDER). Como información adicional en IKEv2 podemos ver las redes remotas y locales que son encriptadas por el túnel. Se puede decir que la información mostrada es de Fase 1 de negociación entre los peers.
En caso de solo necesitar la información de tuneles IKEv1 o IKEv2 se pueden ejecutar los siguientes comandos:
FTD#show crypto ikev1 sa
FTD#show crypto ikev2 saVerificar los tuneles IPSec creados – Fase 2
Para esta fase la negociación entre los peers consiste de esquemas de encriptación de los paquetes utilizando IPSec (transform set) para ello IPsec se apoya del encapsulamiento en ESP (Encapsulating Security Payload) por ello podemos ver estadísticas generales de todos los túneles creados con el comando ipsec stats:
FTD#show crypto ipsec stats
Como se puede apreciar, nos arroja estadísticas de salida y entrada de paquetes comprimidos, encriptados, fragmentados. Más a detalle nos muestra las solicitudes de eliminación de security associations (Inbound SA delete requests, Outbound SA delete request).
Otro comando útil para verificar los túneles es ipsec sa, el cual nos muestra estadísticas de encapsulamiento IPSec en cada traffic selector (redes intersantes) de la VPN, como por ejemplo:
FTD#show crypto ipsec sa
De esta salida podemos identificar un traffic selector para las redes: 10.1.1.0/24 a la red 10.10.242.0/24, su access-list es creada al momento de configurar la VPN a través del FMC, se logra apreciar los peers en ambos extremos del túnel al lado del puerto que se consume (UDP 4500). Un punto muy importante a tener en cuenta son la cantidad de paquetes que se encapsulan, encriptan y se desencriptan por el túnel, esto nos da una idea si esta pasando tráfico a través del mismo. Como pueden apreciar es uno de los comando mas informativos a cerca de la conexión entre los equipos.
A este comando se le puede especificar que peer queremos verificar al ingresa la dirección IPv4 del peer de la siguiente forma:
FTD#show crypto ipsec sa peer <Hostname or A.B.C.D>Verificar la configuracion de los túneles en el running-config
El siguiente comando funciona perfecto cuando requerimos vericar la configuración realizada, de esta manera nos podemos enterar si se nos escapó algún comando:
FTD#show running-config tunnel-groupLa salida de este comando nos muestra los atributos configurados para el túnel, en especial el tipo de autenticación del túnel que en muchos casos es por Pre-shared Key.
Reiniciar tunnel VPN S2S
En caso de querer forzar un túnel a realizar nuevamente la negociación entre los peers desde Fase 1 el comando utilizado es el siguiente:
FTD#clear crypto ikev1 sa <IP-adrress>
FTD#clear crypto ikev2 sa <IP-adrress>Para reiniciar un tunel en Fase 2 el comando utilizado es:
FTD#clear crypto ipsec sa peer <IP-address>Si lo que queremos es limpiar las estadísticas de fase 2 el siguiente comando bastara para reiniciar los contadores:
FTD#clear crypto ipsec sa countersDebugging de problemas
Como mencionaba con anterioridad, las funciones de VPN en los firepower los maneja el motor LINA quiere que los comandos de debugging de los ASA también son válidos en FTD, sin embargo, a pesar que se puedan utilzar y arrojen información útil para el troubleshooting de algún evento, aun no contiene toda la información deseada como lo podemos ver en un ASA, por lo que desde mi punto de vista, el debugging de VPN se debe completar con la GUI a través de la siguiente ventan:
Será en esta ventana donde podamos observar los errores al momento de establecer una VPN S2S o incluso VPN remota. De igual forma dejo por acá los comandos de debugs:
debug crypto ikev2 platform 127
debug crypto ikev2 protocol 127
debug crypto ikev1 127También se puede intentar crear una captura con packet tracer desde la interfaz inside hacia la outside y revisar si el tráfico que pasa a través de la VPN no esta siendo bloqueado por algun otro componente del FTD:
FTD#cap test include-decrypted trace trace-count 100 interface INSIDE match ip host 1.1.1.1 host 2.2.2.2En este ejemplo el trafico interesante de nuestra red local es 1.1.1.1 y de la red remota 2.2.2.2, le decimos que incluya los paquetes desencriptados y corremos la captura.
Con los comandos:
#show cap
#show cap test trace packet-number 1 <-- Verificamos el procesamiento del paquete 1 cuando pasa por los filtros del FTD (traza)En conclusión, nos podemos apoyar de las erramientas que disponiamos de los equipos de previa generación para realizar el troubleshooting adecuado a nuestros enlaces VPN. Espero que les haya gustado mi pequeño tutorial sobre verificación de VPN Site-to-site nos vemos en el proximo blog. Saludes troubleshooters! :D.
OpenSSL: como generar un CSR con SAN
En este post explicaremos cómo crear ó generar un CSR (Certificate Signing Request) creado desde OpenSSL. Como sabremos un CSR es útil en la generación de certificados para la autenticación y cifrado de nuestras comunicaciones SSL. Por otro lado, OpenSSL es un software desarrollado y mantenido por The OpenSSL Project es un software robusto y de grado de comercialización con un completo kit de utilidades para proposito general, para mas información acerca del proyecto visita su página oficial en el siguiente aquí.
Read more: OpenSSL: como generar un CSR con SANInstalación de OpenSSL
Para simplificar las cosas instalaremos OpenSSL desde un archivo precompilado que podremos descargar en la siguiente página: https://slproweb.com/products/Win32OpenSSL.html
Descargaremos la version Light ya que cuenta con lo necesario para nuestro propósito, el formato seleccionado será el .msi damos click en la extensión y automáticamente comenzará la descarga.
Ejecutamos el archivo y nos solicitará la aceptación de licencia, aceptamos y continuamos:
Seleccionamos la carpeta donde se instalará:
Nos mostrará que la instalacion creará un acceso directo en el menú de inicio:
En la siguiente pantalla nos mostrará el directorio donde se instalarán los DLLs del programa:
Para proceder a la instalación tendremos que confirmar las configuraciones previas:
Una vez terminada la instalación nos mostrará la pantalla de donación al proyecto:
En este caso tendremos que añadir el comando “openssl” a nuestro cmd del sistema windows. Para ello nos dirigimos a: >propiedades del sistema -> variables de entorno -> PATH -> New
Verificamos la instalación de OpenSSL desde el CMD de windows con el siguiente comando, el cual tambien funciona para ver la version que tenemos instalada de nuestro OpenSSL:
openssl version
Generando un CSR con SAN usando OpenSSL
Una vez instalado podremos continuar con la generación de nuestro CSR. Podemos iniciar creando una carpeta desde donde crearemos nuestro CSR ejemplor:
En mi caso creé una carpeta en el disco C llamada “openssl”. Para la siguiente tarea deberemos crear un archivo .cfg el cual le cargaremos a openssl y contendrá toda la información que necesitamos para crear nuestro CSR, para ello nos apoyaremos de un notepad, copiaremos la siguiente configuración y posteriormente guardaremos con extension .cfg en la carpeta previamente creada.
[req]
default_bits = 2048
default_keyfile = privatekey.key
distinguished_name = req_distinguished_name
req_extensions = req_ext
[req_distinguished_name]
commonName = Common Name (eg, YOUR name)
commonName_default = host1.domain.com
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = California
localityName = Locality Name (eg, city)
localityName_default = San Jose
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Company Inc
[req_ext]
subjectAltName = @alt_names
[alt_names]
DNS.1 = host1.domain.com
DNS.2 = host2.domain.comComo ven en la configuración anterior, el archivo contiene toda la información necesario para crear un CSR y al final los nombres alternativos es decir los SAN. SAN (subject alternative name) hace referencia a los hostname alternativos que pueden contener este mismo Certificado, por ejemplo:
- 2 servidores web que entregan la misma pagina web pueden contener un mismo certificado con SAN.
- Terminales de VPN que puedan consultar los usuarios bajo el mismo dominio, con una SAN se elimina la creación de un certificado individual para cada equipo.
La configuracion quedaría de la siguiente forma:
Muy importante notar que al inicio del archivo se solicita crear la clave privada en un archivo llamado “privatekey.key” clave asimetrica RSA de 2048 bits.
Ejecutaremos el siguiente comando para generar nuestro archivo .CSR
openssl req -new -nodes -out <nombre_csr>.csr -config <archivo>.cfg
Como ven openssl nos generará las claves, seguido nos solicitará la información del CSR, como colocamos configuración de default en nuestro archivo .cfg solo nos quedaría presionar enter en cada solicitud. Aunque, si quieres modificarlo puedes añadir tu información en cada prompt.
El comando nos generará los siguientes archivos:
En nuestra carpeta tendremos: el archivo de configuración .cfg, el archivo de .csr para crear nuestro certificado, la llave privada de nuestro certificado .key. Es recomendable mantener la clave privada en ordenadores confiables y con actualizaciones al día ya que si por algún motivo esta clave privada se filtra podría vulnerar nuestro certificado público.
En esencia, ya hemos generado los archivos necesarios para enviar a nuestro CA para que pueda generar nuestro certificado, los siguientes pasos: creación de certificado, carga de certificado o conversión de certificado a formato .pfx seran vistos en los siguientes posts.
Saludes troubleshooters! recuerden unirse a nuestro telegram:
Vulnerabilidad: Hypertext transfer protocols (HTTP) Information
El Protocolo de transferencia de hipertexto (HTTP) es el protocolo utilizado para mostrar todos los archivos y otros datos, como páginas web, imágenes, etc., en la World Wide Web. HTTP es un protocolo cliente-servidor sin estado. Un navegador web, que es un cliente HTTP, envía una solicitud a un servidor HTTP. Luego, el servidor responde con el recurso solicitado y cierra la conexión. HTTP 1.0 define 16 códigos de estado. La autenticación en HTTP 1.0 no está encriptada y, por lo tanto, no es segura.
(more…)