Ya ha pasado un tiempo desde mi última publicación en la página, sin embargo estamos retomando labores en publicar y seguir trayendoles nuevo contenido sobre soporte de redes, colaboración y en general de TI.
En este post hablaremos de un caso de soporte bastante común entre usuarios del cliente Cisco Anyconnect. Recordemos que este cliente es usado por los Firewalls ASA y los NGFW Firepower de Cisco, el cliente puede ser utilizado tanto en windows, MAC OS, linux, android y Iphone; aunque en algunas ocasiones por politicas internas, las conexiones VPN no se realizan desde la computadora local sino que es necesario conectarse a un servidor remoto para establecer la sesión.
La siguiente imagen describe el escenario anterior:
Bajo este esquema, el servidor windows es administrado por el usuario de RDP, aunque a primera vista no parece un problema para el uso de aplicaciones instaladas en el server, el cliente anyconnect puede detectar qué tipo de usuario esta loggeado en windows para permitir o no conexiones VPN para dicho usuario. Esta característica se encuentra en su archivo profile, el cual es un archivo XML con las configuraciones locales del cliente.
El archivo se encuentra en la dirección: “C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile”
La clave “<WindowsVPNEstablishment>LocalUsersOnly</WindowsVPNEstablishment>” es quien controla que tipo de usuarios se pueden conectar a través del cliente.
Es usual ver el siguiente error en el cliente Anyconnect: “VPN establishment capability for a remote user is disabled. A VPN connection will not be established.” cuando se intenta realizar conexiones VPN con usuario RDP.
Para permitir usuarios remotos es necesario cambiar el valor de esta clave “LocalUsersOnly” por “AllowRemoteUsers”, se recomienda realizar estos cambios con una copia del archivo XML de preferencia con nuevo nombre.
El nuevo archivo XML modificado deberá de subirse al group policy de la VPN remota en el firewall sea ASA o Firepower, ya que de no reemplazar el archivo en el group policy este seguirá descargandose cada vez que se conecte al perfil de VPN, lo que sobre escribirá la configuracion previamente guardada. Aunque existen hacks como el del blog expta que reemplazan el archivo de profile antes del error de conexion de anyconnect.
El cambio del profile en Firepower Management Center se realiza de la siguiente manera:
1- Cargamos el archivo profile XML desde el Object Management de FMC, dirigiendonos a Objects -> Object management -> VPN -> Anyconnect Files
2- Asignamos el profile XML al group policy deseado:
3- Guardamos cambios y desplegamos la configuración. En este punto la VPN remota tomará los cambios y la proxima vez que se realice una conexión VPN los clientes actualizarán su archivo profile local.
Para finalizar, es recomendable desinstalar e instalar nuevamente el cliente para eliminar cualquier archivo basura que haya quedado en windows.
Con esto concluimos el post y no olviden en comentar cualquier duda o sugerencia para nuestro blog, todo comentario constructivo es bienvenido. 🙂 Hasta la proxima!
En este post se expone un código ejemplo para la creacion de objetos (URL) en Cisco Firepower Management Center utilizando la RestFul API que integrada en la maquina virtual del appliance.
Las RestFul API toman ventaja de la arquitectura de consultas REST utilizado comunmente en servicios WEB para ejecutar comando HTTP con datos normalmente cargados en formato JSON, XML, HTML.
Dentro de Firepower Management Center podemos activar esta caracteristica de la siguiente:
Navegamos a System>Configuration>REST API Preferences>Enable REST API
Activar REST API en FMC
Una vez activado podremos acceder a la pagina principal de REST API de FMC donde encontraremos los URLs, Verbos y tipos de estructuras que se pueden utilizar con la RESTFul API.
La dirección de RESTFUL API es la siguiente: https://<management-api>/api/api-explorer/
Página principal RESTFUL API
Navegando por la página lograremos observar las posibilidades de consulta que se pueden realizar a la RESTFUL API asi como las acciones. En este ejemplo la tarea será crear un objeto sencillo como un URL que puede ser aplicado luego en una Access-rule:
La siguiente imágen muestra la URL utilizada para la creación del objeto así como el verbo a utilizar:
Además de la dirección de la API a utilizar, es requerido el {domainUUID} el cual es un identificador único para cada solicitud en la API
Con esto datos tendremos lo suficiente para realizar la consulta a la RESTFUL API para la creación de objetos URL. La siguiente tarea utilizar un cliente que consuma la RESTFUL API, en mi caso, estoy utilizando Python3 como cliente a través de la libreria ‘Request’ especializada en consultas CRUD para servicios WEB.
La razon por la cual usar Python en lugar de muchos otros clientes con GUI para consumir la API es debido a las extensas posibilidades que me otorga el poder manejar las consultas por un lenguaje de programación de alto y con muchas herramientas disponibles para la manipulacion de objetos. Siguiendo con el ejemplo, solo crearemos un objeto a manera de demostración pero las posibilidades de Python van mucho mas allá como las de crear rutinas para la creación de multiples objetos obtenidos por archivos .CSV por ejemplo.
Creando el script de consumo de API
Cargando script y librerias a utilizar
import json
import sys
import requests
import base64
###Aqui nos deshacemos de un warning de seguridad por el certificado
from requests.packages.urllib3.exceptions import SubjectAltNameWarning
requests.packages.urllib3.disable_warnings(SubjectAltNameWarning)
MIN_ARGS = 3
MAX_ARGS = 4
En el bloque anterior cargamos las librerias necesarias para manipular los datos y realizar las consultas a la RESTFUL API, agregamos 2 variables globales de argumentos para la validación de los datos de entrada.
A continuación, se definen las funciones necesarias para el SCRIPT
Función de Login
RESTFUL API de Cisco requiere autorización por token por lo que es necesario obtener primero un token de autorización para poder consumir la API, la autenticación se realiza por medio de las credenciales de administracion de FMC y estas deben estar codificadas en formato Base64 como es usual en las consultas HTTP:
# Esta funcion administra los temas de autorizacion
def auth_request(url, headers, cert_loc):
# Initialize response
resp = None
# Hacemos el POST para obtener los tokens
## Usamos HTTPS porque es el unico puerto que admite el FMC
if url.startswith("https"):
try:
resp = requests.post(url, headers=headers, verify=False) ## Cambiamos el Verify a False para evitar el uso de certificado
print(resp) ##Este print nos devuelve el codigo de retorno de la solicitud post por HTTP
if (resp == None):
raise ValueError("Response is undefined")
if (resp.status_code != 204):
msg = "Error Status Code: %d in response" % resp.status_code
raise ValueError(msg) ## El Raise es un except pero tiene que ir acompañado
## de un if para validar el error y el error puede se puede definir personalizado
except Exception: ## El exception normal que prueba un bloque de codigo
print("Error Handle auth_request")
## Dentro de este Else se ejecuta si un caso no usamos HTTPS (no recomendado)
else:
resp = requests.post(url, headers=headers)
return resp
def login(server, username, password, cert_loc):
# Direccion API para generar el token
api_path = "/api/fmc_platform/v1/auth/generatetoken"
# Se construye la URL para la consulta
url = server + api_path
## Usuario y contraseña deben ir en formato base64 de la siguiente forma:
'username:password'
##string convertido a base64 en: https://www.base64encode.org/
##String para FMC
authstring = "base64encodedmessage"
print(authstring)
headers = {'Authorization' : authstring}
##En esta funcion se le manda URL y el header de autorizacion con el username y password, cert_loc no es utilizado
try:
resp = auth_request(url, headers, cert_loc)
except Exception:
print("Error Handle login")
##En este caso retorna los headers para authorization y tokens
return {'X-auth-access-token': resp.headers['X-auth-access-token'], 'X-auth-refresh-token': resp.headers['X-auth-refresh-token']}
Función Logout
def logout(server, access_token, cert_loc):
# Direccion para revocacion de token
api_path = "/api/fmc_platform/v1/auth/revokeaccess"
# Construyendo la URL
url = server + api_path
# Header para la revocacion:
headers = {'X-auth-access-token' : access_token}
try:
auth_request(url, headers, cert_loc)
except Exception:
print("Error Handle logout")
return (0)
Como pudieron notar en las ultimas 3 funciones el esquema es el mismo:
Creamos la direccion de URL que se consulta la API: base URL + API URL ejemplo https://192.168.1.1/api/fmc_platform/v1/auth/revokeaccess
Luego creamos los Headers necesarios para la consulta (ejemplo tokens, usuarios, contraseñas)
Finalmente utilizamos el bloque ‘try’ para realizar la consulta ‘request.post’ con toda la informacion generada previamente.
Creamos el objeto que deseamos:
def main():
##Validamos si la informacion ingresada al momento de la ejecucion es correcta:
if len(sys.argv) < MIN_ARGS:
sys.exit("Insufficient inputs. The inputs must have at least 3 arguments \"python auth_util.py <server_addr> <username> <password> <location of certificate>\"")
# sacamos la URL base
server = sys.argv[1]
# obtenemos el usuario
username = sys.argv[2]
print(username)
# obtenemos la contraseña
password = sys.argv[3]
print(password)
# obtenemos el certificado
cert_loc = False
if len(sys.argv) > MAX_ARGS:
cert_loc = sys.argv[MAX_ARGS]
#Nos logeamos a la REST FUL API usando la funcion login:
result = login(server, username, password, cert_loc)
## Del resultado anterior obtenemos los token de autorizacion:
access_token = result.get('X-auth-access-token')
refresh_token = result.get('X-auth-refresh-token')
## validamos si ya existe un token creado
if (access_token != None and refresh_token != None):
print("\nAccess tokens and Refresh tokens exist.")
print("Access token: %s" % access_token)
print("Refresh token: %s\n" % refresh_token)
else:
print("Access tokens and refresh tokens does not exist.")
##Creacion de los objetos para Post aqui tenemos el objeto que vamos a crear en el FMC, notese que es una biblioteca python
post_data_url = {
"type": "Url",
"name": "UrlObject1_test1",
"description": "url object 1",
"url": "http://www.uni.edu.ni"
}
##Obtenemos el URL API Path de la pagina de api-explorer del FMC:
##Domain UUID
api_path = "/api/fmc_config/v1/domain/Domain-UUID/object/urls"
## Armamos el URL Completo:
url_API = server + api_path
##Creamos los headers para el post de URL, notese el header 'Content-Type' que indica que pasaremos un objeto tipo json
headers_url = {'Content-Type': 'application/json'}
headers_url['X-auth-access-token'] = access_token
## Realizamos el post con la libreria request, notese la funcion json.dumps() que convierte una biblioteca python en formato json
try:
r = requests.post(url_API, data=json.dumps(post_data_url), headers=headers_url, verify=False);
status_code = r.status_code
resp = r.text
if status_code == 201 or status_code == 202:
print("Post was successful for " + post_data_url["name"])
# json_resp = json.loads(resp)
# print(json.dumps(json_resp,sort_keys=True,indent=4, separators=(',', ': ')))
else:
r.raise_for_status()
print("Error occurred in POST --> " + resp)
except requests.exceptions.HTTPError as err:
print("Error in connection --> " + str(err))
finally:
if r: r.close()
# Stand Alone execution
if __name__ == "__main__":
main()
Como pudieron observar la creacion de un Objeto usando la RESTFUL API se basa en armar la solicitud POST con los datos necesarios del objeto, en este caso se utiliza JSON como formato para enviar los datos FMC.
Con esto la ejecucion usando la linea de comandos de windows se puede lograr de la siguiente manera:
Para más ejemplos de API con equipos Cisco por refierase a: https://developer.cisco.com/firepower/. Todo el código mostrado acá fue obtenido de los tutoriales de Cisco Developers introductorios a la creación de objetos usando APIs.
Con esto me despido y que tengan exitos en sus Requests 😉 Saludos!!!
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.
Cisco 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
Salida 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 sa
Verificar 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
Salida del comando 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
Salida del comando 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-group
La 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 counters
Debugging 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:
Debug Errores en FMC VPN S2S
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:
Tambié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.2
En 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.
Captura de paquetes sobre la interfaz INSIDE
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.
Desde hace algunos años Cisco ha posicionado la plataforma Firepower como su NGFW (Next Generation Firewall), al día de hoy las series de entrada para esta familia son la serie 1000, 2000. Hoy analizaremos una configuración básica para las interfaces de estos equipos como lo es el servicio de DHCP.
Antes de configurar algún nuevo servicio en nuestros equipos siempre es importante leer la documentación del fabricante sobre las limitantes. En el siguiente link podrán encontrar una guía completa sobre las limitantes y requerimientos para la configuración de DHCP en las interfaces de los equipos administrados Firepower.
Limitaciones DHCP Server FMC
Como observamos en la documentación de las limitaciones más importantes tenemos:
El máximo de direcciones para un pool es de 256, es decir solo asignamos IPs a redes /24.
Solo se puede configurar un servidor DHCP por interfaz, además como veremos mas adelante, la configuración de servidores DNS, dominio, opciones y timeout son globales para todos los DHCP servers en todas las interfaces.
No se puede configurar una interfaz para que tome IP por DHCP si esta ya tiene un servidor DHCP corriendo.
No se puede configurar un dispositivo (FTD) como DHCP Server y DHCP Relay al mismo tiempo.
Para el caso de DHCP Relay tenemos un máximo de 10 a nivel global.
A pesar de las limitaciones que presenta en estos momentos la configuración de DHCP para estos equipos no deja de ser una característica necesaria para nuestra red por lo que en mas de una ocasión estaremos obligados a ocuparla. Es muy probable que en nuevas actualizaciones del sistema se incluyan o retiren ciertas limitaciones al sistema por lo que siempre es recomendable visitar la documentación previo a cualquier configuración.
Configuración
Para la configuración de DHCP asumimos que ya trabajamos sobre un despliegue completo del equipo FTD conectado a Management Center. Desde la GUI del management center nos dirigimos a la siguiente dirección: Devices -> Device management editamos la política de nuestro equipo.
Acceder al device management
Desde Device Management podemos configurar interfáces, enrutamiento, alta disponibilidad y servicios básicos como SNMP y DHCP:
Pestaña de configuración DHCP
DHCP Server
En esta pestaña se nos desplegará la configuración para el DHCP Server. Como mencionamos antes en Cisco Firepower las configuraciones de DNS, dominio, timeout y el tiempo de leasing de IP address son configuraciones globales para todos los DHCP servers:
Configuración global DHCP server
Rellenamos estos campos con los objetos solicitados, en mi caso no utilizo la opción Auto-configuration ya que esto lo que hace es tomar la configuración de DNS, domino y WINS desde un cliente DHCP configurado en alguna de las interfaces del equipo, de ahí que esta ventana solicite una interface.
Ejemplo de configuración global
Con estos campos rellenados procedemos a configurar el pool en una de nuestras interfaces, damos click en add para añadir un nuevo servidor DHCP:
Pool de IPs
Claramente tenemos que añadir un pool de IP que estan bajo la misma red de la interface a la que le activamos el DHCP, antes de guardar activamos el check de “Enable DHCP Server” y de esta forma el servidor que activado en la interfaz, damos click en OK, luego salvamos config y finalmente desplegamos los cambios realizados.
Para agregarle opciones a nuestros servidores DHCP nada mas tenemos que movernos a la pestaña de Advanced:
Añadir opciones al DHCP
Existen ciertas limitaciones a considerar en la configuración de opciones al DHCP, si revisamos nuevamente la documentación podemos leer que existen ciertos codigos que aún no son soportados para esta version de Firepower:
Limitaciones en la configuración de opciones
Configuraremos la opción 150 para nuestro DHCP ya que es usada por teléfonos IPs para descargar plantillas o archivos desde un servidor TFTP:
Ejemplo Configuración Opciones
Para este caso como sabemos que la opcion 150 debe retornar la dirección IP del servidor TFTP al cual los teléfonos deben conectar, entonces configuramos la opción como tipo IP y agregamos las direcciones de nuestros servidores. En caso de utilizar otras opciones lo mejor siempre es revisar la documentación ó RFC en referencia a dicha opción. Nuevamente guardamos y desplegamos.
DHCP Relay
El DHCP Relay funciona retransmitiendo los paquetes DHCPDISCOVER hacia un servidor configurado en la interfaz. Para configurarlo tenemos la pestaña del lado izquierdo y de igual manera tenemos configuración global para todos los DHCP relay:
Configuración global de DHCP relay
Para agregar un agente de relay damos click en Add
Ejemplo configuración relay
En este ejemplo seleccionamos la interfaz INSIDE para retransmitir las peticiones DHCP, activamos el check “Enable IPv4 Relay” para activar el agente de retransmisión y de manera opcional activamos el check “Set Route” si deseamos que el Firepower modifique el paquete de Offer para que la ruta por defecto del cliente siempre sea la interfaz del Firepower por la que entro la solicitud de DHCP. Damos click en OK y salvamos configuración.
Luego de configurar el DHCP Relay debemos configurar un DHCP server, por lo cual nos movemos a la pestaña DHCP Servers:
DHCP servers que responden a los Relays
Damos click en Add para agregar un nuevo DHCP server:
Relay DHCP servers
Como nota en esta configuración el DHCP server no debe alcanzarse desde la misma interfaz a la cual se le confiigura el DHCP relay, es decir si configuramos un DHCP relay por la INSIDE, el servidor DHCP al que se le retransmiten las solicitudes no debe de alcanzarse por la INSIDE.
Verificaciones desde el CLI
Para verificar los Pool y el leasing de nuestros servidores DHCP debemos ingresar por linea de comandos a nuestros equipos, conectarnos al CLI FTD y ejecutar los siguientes comandos:
>show dhcpd state
>show dhcpd statistic
Verificamos las estadísticas generales del DHCP
Para verificar las IPs que se han otorgado ejecutamos el siguiente comando:
>show dhcpd biding all
DHCP Server biding
Con esto se concluyen las tareas de configuración de DHCP en los equipos Firepower. Como vieron siempre es primordial consultar la documentación y verificar las limitaciones de nuestros equipos. Por el momento me despido no sin antes mencionar que se pueden unir a nuestro canal de telegram donde estaremos actualizando contenido sobre la página. Saludos troubleshooters! hasta la proxima!. 😀