el
01-29-2025
04:29 PM
- fecha de última edición
02-07-2025
01:13 AM
por
Jimena Saez
Presentación del webinar Community Live
Con la colaboración de Ricardo Vera, Michel Lepicard y Eduardo Martínez.
Entrenamiento de resolución de problemas de tráfico en el Cisco Firewall Threat Defense (FTD).
En esta sesión, exploramos las herramientas y técnicas esenciales para identificar, diagnosticar y solucionar problemas de tráfico en su red utilizando FTD. También, aprendimos a revisar los registros de eventos y utilizar las herramientas más importantes del FTD para analizar un flujo de tráfico.
Recuerde que la presentación está disponible en pdf para su comodidad. Si este documento le ha resultado útil, no olvide calificar esta publicación con un voto de utilidad para validar su relevancia. ¡Muchas gracias!,
¿Cómo enviar una pregunta?
Ponemos a su disposición nuestro evento Ask Me Anything (AMA) en cuyo foro podrán externar dudas y solicitar apoyo de nuestros expertos en casos específicos de los temas abordados. ¡Esperamos sus preguntas!
Lista de las Q&A del webinar Community Live
Encuentre la lista de preguntas formuladas durante el seminario web Community Live de nuestro evento. Cualquier duda que no haya sido respondida durante la sesión será resuelta posteriormente aquí o en el foro de "Preguntas".
Lista de Preguntas y Respuestas (Q&A)
Respuesta (Yeraldin S.): Hola Natalia, la licencia Base es automáticamente añadida cuando se registra el FTD a la licencia. Para poder hacer uso de las funcionalidades del motor de Snort, se encuentran diferentes licencias dependiendo de la funcionalidad que requieras sería la que se agregaría al dispositivo, te comparto el siguiente documento donde menciona las diferentes licencias que se tienen en la sección de "Smart License Types". https://www.cisco.com/c/en/us/td/docs/security/firepower/70/fdm/fptd-fdm-config-guide-700/fptd-fdm-license.html
Respuesta (César B.): Tenemos algo llamado tabla de conexiones (conn table), ahí veremos las conexiones que se establecen a través del Firewall. Si es un ataque, el Firewall no crea la conexión y sólo veremos los contadores de paquetes tirados incrementar.
Respuesta (César B.): El FTD tiene diferentes tipos de filtrado, desde filtrado por valores del paquete de capa 3, hasta aplicaciones. Si se tiene SSL decryption, podemos también hacer el filtrado por certificados. Para más información, podemos revisar este link https://www.cisco.com/c/en/us/td/docs/security/firepower/70/configuration/guide/fpmc-config-guide-v70/understanding_access_control.html
Respuesta (Christian H.): Nuestros equipos de seguridad dependen de TALOS, el cual se encarga de actualizar nuestras bases de datos con información actualizada sobre los últimos tipos de ataques, dominios e IPs maliciosas, por eso es importante mantener las bases de datos como VDB, SRU, GeoLocation, etc. actualizadas en tu equipo.
Respuesta (Ricardo Vera)*: Esto depende del modelo de FMC, puesto que entre más recursos tenga, más equipos podrá administrar. Si gustas saber más información, en el siguiente link puedes ver la tabla comparativa de modelos de FMC y cuántos equipos pueden administrar: https://www.cisco.com/c/en/us/products/collateral/security/firesight-management-center/datasheet-c78-736775.html#Platformspecifications
Respuesta (César B.): Sí se puede hacer. Más información en el siguiente link. https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html en el apartado de "Work with Snort Engine Captures". El proceso es después de LINA.
Respuesta (Christian H.): Un servidor Proxy actúa como un agente o intermediario para el usuario, transmitiendo todas las solicitudes y respuestas web. Un firewall inspecciona los paquetes (tráfico de red) cuando entran y/o salen de una red o sistema informático, y toma medidas cuando uno o más de sus reglas de seguridad son violadas por los paquetes o sus orígenes. Dicho eso, nuestros FTDs NO funcionan como Proxy, pero son capaces de inspeccionar el tráfico HTTP y HTTPS para aplicar políticas de filtrado de contenido.
Respuesta (Christian H.): ¿A qué te refieres con secuestro de sesión? Si te refieres a un Man in the Middle attack, entonces dependes 100% de si tu tráfico está encriptado o no. Si el tráfico capturado viaja a través de una VPN, entonces el atacante no podrá ver tu tráfico, pero sí ve en texto plano, ahí si habrá problemas.
Respuesta (Yeraldin S.): Hola, Diego! Se requiere un licenciamiento de acuerdo con la funcionalidad que se dese utilizar, te comparto el documento con más información sobre cada licencia (Threat, Malware, URL) para un FTD https://www.cisco.com/c/en/us/td/docs/security/firepower/70/fdm/fptd-fdm-config-guide-700/fptd-fdm-license.html
Respuesta (Yeraldin Sánchez)*: Hola Rafed, se requiere de un licenciamiento de acuerdo con la funcionalidad que se desee utilizar. Te comparto el documento con más información sobre cada licencia (Threat, Malware, URL) para un FTD https://www.cisco.com/c/en/us/td/docs/security/firepower/70/fdm/fptd-fdm-config-guide-700/fptd-fdm-license.html
Respuesta (Yeraldin S.): Hola, Luis! Se requiere un licenciamiento de acuerdo con la funcionalidad que se desee utilizar, te comparto el documento con más información sobre cada licencia (Threat, Malware, URL) para un FTD https://www.cisco.com/c/en/us/td/docs/security/firepower/70/fdm/fptd-fdm-config-guide-700/fptd-fdm-license.html
Respuesta (Yeraldin S.): LINA es un motor que se encuentra en dispositivos como el ASA y el FTD, éste es responsable de realizar verificaciones de estado TCP y comprobaciones de listas de control de acceso (ACL) de nivel 3 y 4.
Respuesta (Christian H.): El software de los FTDs SIEMPRE incluye ambos engines, LINA y SNORT, independientemente del tipo de instalación del FTD.
Respuesta (Christian H.): Nuestro FTD tiene un SSL decryption engine dedicado a estas funciones, te dejo un link que puedes revisar para más detalles de este proceso y sus alcances: https://www.cisco.com/c/en/us/td/docs/security/firepower/70/fdm/fptd-fdm-config-guide-700/fptd-fdm-ssl-decryption.html
Respuesta (César B.): Sí, QoS siempre va a estar analizando los niveles de tráfico, una vez que los valores superen el límite, se aplicarán las medidas configuradas.
Respuesta (César B.): La integración sólo requiere la licencia base, ya dependiendo qué se quiera hacer después será la licencia necesaria.
Respuesta (Christian H.): Para ataques de día Cero, tienes la capacidad de crear IPS signatures manuales para hacer match a las condiciones del ataque. | Para dominios que el FW no tiene en su base de datos local, puedes configurar el FW para que pregunte al cloud de TALOS en tiempo real | Tiempo de sandboxing, no hay un valor específico, dependes del query y análisis.
Respuesta (Eduardo Martínez)*: Aquí puedes integrarlo con un Active Directory, por ejemplo, el FMC descarga los usuarios de ahí. Y de ahí se tiene que ocupar un identity source, puede ser ISE o a partir de 7.6, Cisco passive identity agent, que es quien hace mapeo de usuarios con IPs.
Respuesta (Cesar B.): Oliver, ¿diferencia en cuanto a qué? ¿Podrías darnos más detalles?
Respuesta (Yeraldin S.): LINA es un motor que se encuentra en dispositivos como el ASA y el FTD, éste es responsable de realizar verificaciones de estado TCP y comprobaciones de listas de control de acceso (ACL) de nivel 3 y 4.
Respuesta (César B.): Sí se puede customizar, solo hay que tener cuidado con los parámetros, porque podríamos afectar el performance del Firewall. Más información en el siguiente link: https://www.cisco.com/c/en/us/td/docs/security/firepower/640/configuration/guide/fpmc-config-guide-v64/threat_defense_service_policies.html
Respuesta (Yeraldin S.): La capa DAQ (Adquisición de Datos) se refiere a la capa responsable de la recopilación y gestión de datos de tráfico de red para su análisis.
Respuesta (César B.): Si es posible. Más información en el siguiente link: https://www.cisco.com/c/en/us/td/docs/security/firepower/70/configuration/guide/fpmc-config-guide-v70/control_users_with_remote_access_vpn.html
Respuesta (Yeraldin S.): Este tiempo es variable y depende de muchos factores, tamaño del paquete y la configuración que tengan los dispositivos para su análisis.
Respuesta (Yeraldin S.): Cuando se utiliza la acción fastpath en una regla de prefiltrado, el tráfico coincidente omite la inspección y simplemente se transmite a través del dispositivo. Se utiliza esta acción para el tráfico en el que se puede confiar y que no necesariamente se beneficiaría de ninguna de las funcionalidades de análisis de tráfico.
Respuesta (Christian H.): Si solo tienes tu FTD y no un FMC para administrarlo, entonces debes de activar la administración GUI local a través del FDM. Esto asume que tienes una implementación pequeña y puede haber ciertas funcionalidades limitadas a comparación con un FMC: https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/roadmap/device-manager-new-features-by-release.html
Respuesta (Christian H.): Depende del tipo de tráfico que mandes a través de la VPN, el Prefilter/Fastpath se recomienda aplicar a tráfico confiable en la red como tráfico encriptado (VPN), de protocolos de enrutamiento como EIGRP, OSPF, BGP y para tráfico de bases de datos o backups, independientemente de si va a través de una VPN o no.
Respuesta (Christian H.): Exactamente, los FWs tiene una tabla de conexiones, esa tabla guarda las sesiones establecidas y cuando recibe tráfico de interfaces no seguras, el FW busca conexiones previamente establecidas en su tabla de conexiones, si no encuentra una conexión preestablecida, entonces bloquea la conexión. Para conexiones que vienen de interfaces no seguras y no tienen conexiones preestablecidas, requieres crear reglas en el FW para permitir su ingreso.
Respuesta (Yeraldin S.): Son diferentes acciones. La acción "Trust" normalmente se utiliza para el tráfico que se considera seguro y no requiere inspección adicional, como el tráfico interno o ya verificado.
Respuesta (Ricardo Vera)*: Hola, dependiendo del modelo será si necesite licencias. Generalmente los modelos físicos traen una licencia base, y para algunas características se pueden necesitar licencias extra (como para configuraciones de VPN). En cuanto a el tema de SD-WAN, el firewall no tiene características relacionadas a SD-WAN.
Respuesta (Christian H.): El servidor de DNS es REQUERIDO cuando los Hosts en la red buscan destinos usando nombres de dominio, si tu host sólo busca destinos en base a IPs, entonces no requieres un servidor DNS.
Respuesta (Christian H.): Nuestros productos Cisco se siguen actualizando constantemente y siguen buscando la integración de varias tecnologías Cisco e incluso de otras marcas, esta integración sigue en proceso de mejora continua, te invito a revisar nuestra doc de XDR para confirmar las tecnologías y marcas con las que se integra actualmente: https://www.cisco.com/c/en/us/products/security/xdr/integrations.html
Respuesta (Christian H.): Lo que tienes que estar actualizando constantemente son las bases de datos que dependen de la info que actualiza TALOS sobre los nuevos ataques, IPS signatures, IPs y dominios maliciosos, como son las bases de datos de VDB, SRU, LSP and GeoDB.
Respuesta (Cesar B.): El ASA con Firepower SM también se puede integrar al FMC. Pero si lo manejas con ASDM, si vas a sentir diferencias. Pero en cuanto a capabilidades, el FMC tiene muchas más cosas soportadas comparado con el ASDM.
Respuesta (Yeraldin S.): LINA es un motor que se encuentra en dispositivos como el ASA y el FTD, éste es responsable de realizar verificaciones de estado TCP y comprobaciones de listas de control de acceso (ACL) de nivel 3 y 4.
Respuesta (Yeraldin S.): SI brinda una oportunidad temprana de descartar tráfico no deseado según la dirección IP de origen/destino o la URL de destino.
Respuesta (Christian H.): Así, los security events del FMC nos mostrarían la razón por la cual se bloqueó el tráfico y también desde el CLI se podría revisar que regla puntualmente bloqueo el tráfico. Cisco TAC te puede apoyar con el CLI analysis.
Respuesta (Ricardo Vera)*: Dentro de las mismas fases que generan los traces en las capturas, te va a indicar si el drop fue debido a LINA o si fue en una fase utilizada por Snort.
Respuesta (Ricardo Vera)*: Dependerá mucho del escenario, pero como regla general, el tráfico denominado como "Elephant Flows", tráfico relacionado con VOIP o aplicativos de streaming, suelen ser los que se configuran para ser omitidos por la inspección de Snort.
Respuesta (Ricardo Vera)*: Es correcto, si un FTD está registrado a un FMC y posteriormente queremos cambiar el modo de adminsitración por FDM, las configuraciones serán perdidas.
Respuesta (Ricardo Vera)*: A partir de la versión 7.6 se puede integrar el FMC con Cisco Security Cloud, y con ello habilitar el AI Assistant. Si quieres conocer más información puedes consultar aquí: https://secure.cisco.com/secure-firewall/docs/ai-assistant
Respuesta (Ricardo Vera)*: LINA es un motor que se encuentra por defecto en los dispositivos ASA y FTDs, por lo que, si cuentas con alguno de esos dispositivos, ya estarías utilizando LINA.
Respuesta (Ricardo Vera)*: Las políticas de archivos, inspección y demás características que utilicen Snort, son configuradas manualmente por los usuarios, ya sea por medio de un FMC o en su defecto por el administrador FDM. En cuanto a la base de datos que utiliza Snort para poder hacer sus veredictos, constantemente salen actualizaciones que ponen al día las reglas para las más recientes vulnerabilidades y amenazas.
Respuesta (Ricardo Vera)*: Las capturas son bidireccionales, es decir, el tráfico que se reciba y salga por la interfaz configurada se verá ahí. Sin embargo, se aconseja que se coloquen capturas tanto en la interfaz de ingreso, como de egreso, para poder corroborar que no existen paquetes tirados, y que lo que entra por una interfaz sale simétricamente por la otra.
Respuesta (Ricardo Vera)*: No es posible repetir el nombre de una captura configurada previamente, se necesita configurar nombres distintos. Saludos.
Respuesta (Ricardo Vera)*: Las capturas se colocan sobre interfaces, como tal, a cualquier captura se le pueden configurar puertos para delimitar el tráfico capturado.
Respuesta (Jimena Saez Sanchez): Hola Alex, la presentación está aquí https://community.cisco.com/t5/documentos-seguridad/doc-troubleshooting-de-tr%C3%A1fico-de-datos-y-control-en-el-ftd/ta-p/5254519?attachment-id=235643
Respuesta (Yeraldin S.): Se tendrían que especificar el puerto de entrada y el de destino.
Respuesta (Ricardo Vera)*: Correcto, sí es posible configurar capturas desde el FMC. Aquí te dejo el procedimiento de cómo realizarlo: https://www.cisco.com/c/es_mx/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html#toc-hId--688669429
Respuesta (Ricardo Vera)*: La manera en que se puede inspeccionar el tráfico cifrado, es a través de una política de SSL, en donde se configura el firewall para tener acceso a las llaves que pueden descifrar este tráfico, y por este medio una vez que se tenga conocimiento de qué tipo de contenido es, se inspeccione.
Respuesta (Ricardo Vera)*: Principalmente que los ASA solamente tienen el motor de LINA y están muy limitados en cuanto a inspección de capa 7, los FTD pueden hacer esta inspección de capa 7 (a través de Snort), y esto les permite proteger desde más campos la red.
Respuesta (Ricardo Vera)*: Correcto, es posible configurar capturas desde el FMC, aquí te dejo el procedimiento de cómo realizarlo: https://www.cisco.com/c/es_mx/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html#toc-hId--688669429
Respuesta (Ricardo Vera)*: Así es, Umbrella puede integrarse con el FTD. Si deseas información de cómo realizarlo, te dejo una guía del procedimiento: https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/integrations/umbrella-dns/configuring-the-umbrella-dns-connector-for-cisco-secure-firewall-management-center.html
Respuesta (Michel L.): Las captura también se pueden realizar desde el FMC para esto tenemos que ir Devices-> Packet Capture
Respuesta (Ricardo Vera)*: Se podría realizar de manera manual al comparar diferentes paquetes individualmente, y revisar de donde viene la Mac address en uno y otro.
Respuesta (TBC): (en espera)
Respuesta (Ricardo Vera)*: Dependiendo el modelo pueden variar la cantidad de interfaces de datos que se tienen, sin embargo, la mayoría tienen 8 interfaces o más con puerto RJ-45, además de las interfaces para fibra óptica (SFP).
Respuesta (Eduardo Martínez)*: Snort usa las reglas de Inteligencia de seguridad (SI) para hacer esto, dependiendo de si es IP, lo bloquea desde el primer paquete, si es una URL o dominio, puede tardar de 3 a 5 paquetes en detectarlo y ahí es donde el SI entra y bloquea.
Respuesta (Ricardo Vera)*: Lina y Snort vienen exclusivamente en Firewalls que estén corriendo software FTD.
Respuesta (Ricardo Vera)*: Lamentablemente desde el 2022, los modelos ASA con módulos FTD ya no están en venta, ni tienen soporte de software. Puedes referirte a este link para revisar más información acerca de esto: https://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/asa-5585-x-firepower-services-modules-1yr-subscriptions-eol.html
Respuesta (Ricardo Vera)*: Los paquetes saldrán con la misma dirección MAC de origen, puesto que el Firewall no va a manipularlos. Si en todo caso determina que es un paquete malicioso, lo va a tirar; pero si es admitido, entonces saldrá igual que como entró.
Respuesta (Ricardo Vera)*: Muy similar a lo que dijiste, sólo con una pequeña corrección, Lina trabaja hasta la capa 4 y Snort efectivamente trabaja en capa 5, 6 y 7.
Respuesta (Ricardo Vera)*: Efectivamente, las capturas cuentan con un buffer por defecto de 500 bytes, esto puede ser incrementado hasta 32MB. Si se llenase el buffer de la captura, los paquetes capturados permanecerán en la captura hasta el punto donde se llenó, a menos que se vacíe el contenido. Una pequeña aclaración es que no se van a remplazar los paquetes previamente capturados por paquetes nuevos, sino que se quedarán ahí hasta que sean eliminados manualmente.
Respuesta (Ricardo Vera)*: En un FTD hay diferentes consolas, por lo que para poder ejecutar comandos de LINA, se podrán utilizar en la consola denominada "CLISH" (la cual abre por defecto cuando se conecta a un FTD por SSH) o bien, a través de la consola "diagnostic-cli". En ASA solamente se corre LINA, por lo que una vez entremos a la consola por SSH, podremos ejecutar comandos de LINA.
Respuesta (Ricardo Vera)*: Para errores de transmisión y recepción de paquetes no se utilizan capturas, sino se revisan los buffers con el comando "show interface", similar a como se hace con otros equipos de redes Cisco (routers y switches).
Respuesta (Ricardo Vera)*: Así es, las capturas cuentan con un buffer por defecto de 500 bytes y pueden ser incrementado hasta 32MB.
Respuesta (Ricardo Vera)*: Me parece que te refieres al Firewall Migration Tool (FMT) que se utiliza para migrar un ASA a un FTD. Aquí te dejo más información al respecto: https://www.cisco.com/c/en/us/products/security/secure-firewall-migration-tool/index.html
Respuesta (Ricardo Vera)*: Todos los modelos sin importar que corran ASA o FTD, pueden correr capturas de paquetes. Solamente los debugs de Snort son exclusivos al FTD, puesto que ASA no corre Snort.
Respuesta (Ricardo Vera)*: Las capturas cuentan con un buffer por defecto de 500 bytes y pueden ser incrementado hasta 32MB. Estas consumen recursos de CPU, y dependiendo de cuántas se tengan configuradas al mismo tiempo, pueden afectar el performance o desempeño de los equipos. Se recomienda eliminar las capturas una vez se haya terminado la investigación por lo mismo.
Respuesta (Ricardo Vera)*: Se utiliza para monitorear el tráfico en la red y construir un mapa comprensivo de los activos de la red.
Respuesta (Ricardo Vera)*: Se hacen las capturas al mismo tiempo, mientras el tráfico no está fluyendo sobre el firewall. Una vez que se tengan configuradas, ahora sí se lanza el tráfico al firewall y se analiza cómo se comportó el tráfico al ingresar y salir de las interfaces.
Respuesta (Ricardo Vera)*: Principalmente características que utilicen Snort como inspección de archivos, decifrado de tráfico SSL o bien la inspección de reglas. Es importante mencionar que es esperado que estas inspecciones generen latencia, sin embargo, existen límites aceptables dentro de esta latencia, la determinación de si es válido o no, dependerá de cada caso.
Respuesta (Ricardo Vera)*: Depende de cómo esté configurado tu firewall; puede ser que no tengas configuradas políticas de inspección, pero en las reglas de acceso sí configures una inspección default. Si en todo caso lo deseado es que el tráfico no se inspeccione por Snort, las dos opciones disponibles son configurar reglas de control de acceso con acción "Trust", o bien, hacer una política de Prefiltrado y agregar el tráfico deseado.
Respuesta (Ricardo Vera)*: Esto es una investigación más a fondo, realmente no hay un comando que te diga específicamente si hay un proceso o una tarea que esté causando latencia. Si tienes un problema de ese estilo, te recomiendo abrir un caso con TAC.
Respuesta (Ricardo Vera)*: Sí puede generar problemas de performance como cualqueir debug, por lo que se recomienda que una vez se haya revisado lo deseado, se pare el debug.
Respuesta (Ricardo Vera)*: Puede generar problemas de recursos de CPU, lo que puede derivar en problemas de performance a la hora de trabajar con el tráfico que pasa a través del firewall. No podríamos decirte un porcentaje o cifra específica, ya que dependerá de cuántas capturas tengas activas al mismo tiempo y del modelo del firewall; pero como regla general, siempre recomendamos eliminar las capturas después de ser utilizadas, y no dejarlas configuradas ni corriendo indefinidamente sobre el firewall.
Respuesta (Ricardo Vera)*: Es una excelente pregunta! La mayoría de los FTDs tienen configurado por defecto accesar a CLISH cuando entramos por SSH. Te dejo una guía de cómo identificar los sub-tipos de consolas, y de cómo saber la manera de acceder a ellas: https://www.cisco.com/c/en/us/td/docs/security/firepower/command_ref/b_Command_Reference_for_Firepower_Threat_Defense/using_the_FTD_CLI.html#wp3783114587
Respuesta (Ricardo Vera)*: Sería muy raro que lleguen a generar un crash en la caja por sí solas, lo más común es que afecten el rendimiento en que procesan los paquetes de datos, sin embargo esto dependerá de un caso a otro.
Respuesta (Ricardo Vera)*: Es correcto, ambas acciones elevan el proceso de CPU en el equipo. Se recomienda que una vez se terminen de utilizar, se eliminen las capturas o se detenga el debug, puesto que dejarlos indefinidamente causa problemas de performance o desempeño.
Respuesta (TBC): (en espera)
Respuesta (Ricardo Vera)*: No tenemos un documento como tal para describir la capacidad de Access Control Elements, sin embargo, sí tenemos un documento que describe todos los tipos de configuraciones de Control de Acceso, así como las mejores prácticas. Te dejo el link por aqui: https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212321-clarify-the-firepower-threat-defense-acc.html
Respuesta (Ricardo Vera)*: Con la licencia base puedes filtrar tráfico URL manualmente, definiendo los sitios web que te gustaría permitir o bloquear. Sin embargo, para bloquear URLs por categoría o reputación, es necesario tener una licencia de URL Filtering. Te dejo más información al respecto: https://www.cisco.com/c/en/us/td/docs/security/firepower/70/configuration/guide/fpmc-config-guide-v70/url_filtering.html#Cisco_Reference.dita_dd1565e3-8c10-4ed5-b0a4-293da7194474
Respuesta (Ricardo Vera)*: El procedimiento para configurar la inspección en una regla de Control de Acceso, es un proceso que se configura en la sección de "Inspection". Te dejo el link para que puedas revisar el procedimiento: https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/720/management-center-device-config-72/intrusion-get-start.html#ID-2177-00000141
Respuesta (Christian Hernández)*: Para ver logs de VPN en el FMC debes ir a Devices > VPN > Troubleshooting, como se indica en nuestra documentación oficial (Viewing VPN System Logs): https://www.cisco.com/c/en/us/td/docs/security/firepower/630/configuration/guide/fpmc-config-guide-v63/firepower_threat_defense_vpn_troubleshooting.html#id_47290
Tambien tenemos la opción de mandar logs del FTD hacia un servidor externo, o verlos en tiempo real desde el buffer en el CLI (show logging), estos son los syslog IDs que puedes utilizar para monitorear logs de establecimiento de una VPN:
1. 713903: This syslog ID indicates a successful Phase 1 (IKE) negotiation for site-to-site VPNs.
2. 713904: This syslog ID indicates a successful Phase 2 (IPsec) negotiation for site-to-site VPNs.
3. 713119: This message indicates that a remote user has successfully connected to the VPN.
4. 113019: This syslog message indicates a successful establishment of an IPsec tunnel.
5. 113005: This message indicates an IPsec SA (Security Association) was created.
6. 113039: This syslog message indicates that a VPN session was disconnected.
Respuesta (Ricardo Vera)*: La decisión de esto dependerá de las políticas internas de tu compañía, y si es permitido o restringido. Como medida de seguridad puede ser útil que los firewalls no contesten los ping desde ninguna interfaz de datos, sin embargo, esto variará de un caso a otro.
Respuesta (Ricardo Vera)*: Depende del tipo de laboratorios, puesto que en algunos casos por la complejidad necesitamos utilizar equipos físicos, y en otros casos virtuales. Mi sugerencia: si deseas realizar laboratorios para aprender un poco más acerca de la plataforma, podrías comenzar con entornos virtuales.
Respuesta (Ricardo Vera)*: Así es, TALOS es el proveedor de los "Security Intelligence Feeds", si gustas saber más información te dejo la siguiente liga: https://www.cisco.com/c/en/us/td/docs/security/firepower/710/fdm/fptd-fdm-config-guide-710/fptd-fdm-sec-intel.html
Respuesta (Ricardo Vera)*: No estoy seguro a qué te refieres con modelo de ataque continuo. Si te refieres a un ataque DDOS, los firewalls no son un mecanismo de defensa que puedan apoyar en situaciones de ese estilo; sin embargo, para algunos modelos se puede instalar la aplicación de Radware vDefense Pro, la cual sí sirve como mecanismo de defensa en el escenario de un ataque DDOS. Te dejo más información al respecto: https://www.cisco.com/c/en/us/td/docs/security/firepower/quick_start/radware/radware_ftd_qsg.html
Respuesta (Ricardo Vera)*: Es correcto, te dejo el link con la información correspondiente a nuestras certificaciones relacionadas a ciberseguridad: https://www.cisco.com/site/us/en/learn/training-certifications/certifications/cybersecurity/index.html
Respuesta (Ricardo Vera)*: No, no es posible configurar el FTD o ASA como un proxy tradicional de red.
Respuesta (Ricardo Vera)*:
Si un tráfico es permitido desde una Zona1 hacia Zona2, la conexión de regreso de Zona2 a Zona1 será permitida.
Sin embargo si un servicio es permitido de Zona1 a Zona 2 y el inicio de la conexión se recibe por Zona2, el tráfico será rechazado ya que no fue configurado para accesar desde Zona2 a Zona1.
Es posible configurar reglas bi-direccionales para un escenario en donde no nos importa si la conexión está previamente establecida, como lo mencionas, pero se necesita estipular explícitamente.
Respuesta (Ricardo Vera)*: Efectivamente, ese L3/L4 ACL es la regla de control de acceso que configuramos. Si requieres más información de esto, puedes revisar esta liga: https://www.cisco.com/c/es_mx/support/docs/security/firepower-ngfw/212321-clarify-the-firepower-threat-defense-acc.html
Respuesta (TBC): Así es, una regla de control de acceso con acción "Allow" inspeccionará el tráfico a través de Snort a pesar de ser permitido; si usamos la acción "Trust", el tráfico será permitido y no será inspeccionado por Snort, similar a colocarlo en una regla de prefiltrado.
Respuesta (Ricardo Vera)*: Generalmente se identifican patrones de conducta a través de paquetes duplicados en capturas. Sin embargo es un tema más complejo, en caso de tener una situación así, es recomendable abrir un caso con TAC para el diagnóstico.
Respuesta (Ricardo Vera)*: Existe una certificación para Next Generation Firewalls de Cisco, el examen es el 300-710 y hay una guía que se llama "CCNP Security Cisco Secure Firewall and Intrusion Prevention System Official Cert Guide", esa puede servirte para aprender más de la plataforma.
Respuesta (Eduardo Martínez)*: Sí es posible, dependiendo del escenario, podrian hacer uso del include-decrypted o si bien el paquete ya entró al FTD, el FTD lo desencripta y no es necesario usar el comando, el FTD tendria visibilidad. Pero es dependiendo del escenario.
Respuesta (Ricardo Vera)*: Es correcto, sí pueden ser integrados con SD-WAN, te dejo una guía con más información al respecto: https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/usecase/b_wan-deployment/m_introduction.html
Opciones de respuesta: a) Transporte b) Sesión c) Red d) Enlace de datos // Respuesta Correcta: c) Red
Opciones de respuesta: a) Establecer una conexión b) Finalizar una conexión c) Sincronizar una red d) Notificar acerca de un problema en la red // Respuesta Correcta: a) Establecer una conexión
Opciones de respuesta: a) Verdadero b) Falso // Respuesta Correcta: b) Falso
Opciones de respuesta: a) Paquetes filtrados b) Paquetes enviados c) Paquetes recibidos d) Paquetes de tráfico ARP // Respuesta Correcta: c) Paquetes recibidos
Nuestros expertos
Ricardo Vera se incorporó a Cisco en 2021 con el rol de Technical Consulting Engineer para el Centro a Asistencia Técnica (TAC) de Cisco, en el equipo de Next Generation Firewall. A lo largo de su carrera profesional se especializó como experto certificado en su tecnología y actualmente se encuentra desempeñando el rol de Líder de Equipo en México, asistiendo a clientes en situaciones complejas alrededor del mundo.
Michel Lepicard se unió a Cisco en 2020, certificándose como experto en el área de networking. Posteriormente, se incorporó al equipo de Next Generation Firewall, donde rápidamente se convirtió en uno de los mejores miembros del equipo técnico. Actualmente, desempeña el rol de ingeniero de escalación para su equipo, demostrando su habilidad y conocimiento en el campo.
Eduardo Martínez se incorporó a Cisco hace tres años, trayendo consigo más de seis años de experiencia en el área de seguridad. Es un especialista certificado en Firepower y actualmente se desempeña como Senior Engineer en el equipo de Next Generation Firewall en México. Eduardo apoya al equipo de BETA, enfocándose en revisar la calidad de las versiones de software más recientes para asegurar su eficacia y estabilidad. Su dedicación y conocimiento han sido fundamentales para el éxito del equipo y la satisfacción de los clientes.
¡Conecte con otros expertos de Cisco y del mundo! Encuentre soluciones a sus problemas técnicos o comerciales, y aprenda compartiendo experiencias.
Queremos que su experiencia sea grata, le compartimos algunos links que le ayudarán a familiarizarse con la Comunidad de Cisco:
Navegue y encuentre contenido personalizado de la comunidad