Introducción
Julio Carvajal es ingeniero del Centro de Asistencia Técnico de Cisco Latinoamérica especializado en tecnologías de seguridad y centros de datos. Julio es experto en problemas de seguridad en ruteadores, Adaptive Security Appliances (ASAs), y sensores de sistemas de intrusión y prevención (IPS), entre otros. Julio tiene la certificación de Cisco CCSP y se prepara para obtener la certificación de CCNP. Julio es un colaborador activo en las Comunidades de Soporte de Cisco en inglés y en español.
Iván Martiñón fue el experto que estuvo ayudando a Julio a contestar algunas preguntas que se hiceron durante la sesión en vivo.
El evento de Pregunte al Experto relacionado con este tema esta disponible aquí. Puede accesar el video de la sesión en vivo, aquí. En este documento aquí encontrará la presentación utilizada por Julio.
P. Más allá de la utilización de objetos ¿Es posible en una ACL la utilización de un FQDN a resolver por un DNS Server? Ejemplo, en el destino poner www.cisco.com
R. sí, el ASA puede usar FQDN en las listas de acceso hasta cierto nivel, por favor visita esta liga para mayor información:
https://supportforums.cisco.com/docs/DOC-17014
P. ¿Hay en roadmap previsión para incluir PBR en los ASAs?
R. Hasta el momento no se ha planeado incluir PBR como una funcionalidad del ASA.
P. ¿Tienes el número del bug mencionado en la version 8.4.2 que afecta el NAT entrante?
R. A: Ricardo, Julio pondra el bug ID en el evento de Pregunte al experto que se abrio hoy. Podras hacer mas preguntas a Julio en
https://supportforums.cisco.com/thread/2169082
P. Si IPv6 promueve el uso de IPs públicas ¿Qué futuro tiene el uso de NAT en los firewalls?
R. Actualmente los Firewalls de Cisco dan soporte para características limitadas para IPv6; hasta el momento no se ha mencionado nada referente a la desaparición de NAT en los Firewalls (ASA, ASA-SM, etc)
P. ¿El tráfico puede pasar de una interfaz de mayor seguridad a una menor, sin configurar NAT entre las interfaces?
A partir de 8.3 sí, debido a que el comando de Nat Control desaparece
P. ¿Sobre el ASA se puede realizar balanceo de carga?
R. No, el balanceo de carga o PBR no son soportados por ASA
P. ¿Qué es SLA? ¿Qué significa? ¿Para qué sirve?
R. Servicel Level Agreement. Como su nombre lo dice, es un acuerdo de servicio donde siempre se va a buscar redundancia con respecto a las rutas estáticas. Por ejemplo, si tenemos una ruta estática hacia una oficina remota y queremos siempre tener acceso a esa ruta; de igual manera, si nuestro ISP se va abajo entonces configuramos el SLA que nos permitirá determinar si nuestro ISP dejó de funcionar, buscar una ruta alterna para esa oficina. Entonces, es básicamente redundancia.
P. Tengo un cisco ASA 5500 series ¿Dónde puedo descargar las actualizaciones necesarias para el IOS?
R. Directamente de la página cisco.com Ahí buscan la descarga de software, escribes ASA 8.3 y posteriormente aparece el link donde puedes descargarlo. Recomendable que siempre que vayan a realizar la mejora, lo hagan desde 8.2 He visto casos que lo hacen desde 8.0 y no tienen problema pero recomendaría que se hiciera de 8.2 a 8.3 ya que es la más cercana y los cambios van a ser hechos automáticamente por el ASA.
P. ¿Los cambios de NAT sólo se hicieron en los ASAs? ¿O tambien en otros equipos de Cisco?
R. Se realizaron sólo en el ASA
P. ¿Cuándo se utiliza source y destination a la hora de crear un objeto de servicios TCP o UDP?
R. Siempre que la interfaz asociada al puerto o al servicio que queremos accesar se va a determinar si es source o destination. Si tenemos un Nat inside-outside y el tráfico que vamos a traducir va a estar ubicado en el inside, entonces será origen. Esto resulta tan sencillo como asociarlo al origen de las interfaces dentro del paréntesis. Si está primero es source, si está segundo es destination.
P. Si quisiera realizar un NAT para cuando voy hacia una IP específica ¿Cómo lo haría?
R. Eso se realiza mediante el doble NAT, recordemos que ese toma el orden de procedencia número 1, por ende va a ser revisado desde el primero. Es como se le conoce como Policy NAT en versiones anteriores. Ahora, simplemente creas tres objetos: el objeto para tu red interna, si quieres traducirla creas otro objeto a la cual se debe de traducir esa red interna y creas el objeto destino. De igual manera puedes traducir el destino, sólo creando un objeto alterno
P. ¿Por qué es necesaria tanta memoria para poder pasar de 8.2 a 8.3?
R. Porque a partir de 8.3 van a haber un sinfin de posibilidades nuevas que van a requerir que el ASA cargue más memoria de RAM al iniciar. Como les dije, en el 8.3 existen diferentes funcionalidades superiores a las que cuenta 8.2
P. Cuando falla la primaria y al tiempo vuelve a subir ¿El ASA toma esta ruta de nuevo de forma automática?
R. Sí, de forma automática y dinámica. Debido a que esta ruta va a tener una métrica menor. Tan pronto como ese objeto configurado comience a responder a esos paquetes de ISMP, el ASA de manera dinámica y automática va a tomar de nuevo la ruta primaria
P. En la VPN el Peer es la direccion IP de la outside, con un SLA ¿él siempre escoje la misma? sabiendo que hay dos direcciones
R. No, en el dispositivo remoto se deben crear si es IPSec, LAN to LAN se deben crear dos Crypto Maps. Uno apuntando a la interfaz primaria y otro a la secundaria.
P. ¿Para las vpn es necesario configurar el NO NAT? ¿o ya no hace falta?
R. Es necesario configurar de igual manera el NAT, éste va a ser conocido como doble NAT. Si no queremos realizar la traducción se le conoce como el NAT de identidad, sólo se crea el NAT inisde-outside con el mismo source dos veces porque no se quiere tradicir y en el destination se pone un objeto conteniendo al red interna sin traducirse. Es importante recalcar que en el 8.4.2 hay un bug en el cual el si el tráfico es iniciado desde la oficina remota y quiere accesar nuestro ASA a la interfaz interna se usa el comando route_lookup, sin este comando el tráfico hacia el ASA no será transmitido
P. ¿Se puede hacer upgrade de un asa 6.0 a un 8.3? ¿Qué necesito?
R. Es recomendado por nosotros ir siempre de 8.2 a 8.3 He visto casos que van de 8.0 a 8.3 y no les causa problemas. Pero si ustedes buscan información relativa a las mejoras de la versión del ASA, hay un camino que se debe de seguir para evitar los problemas. En este caso, él debería ir a 8.2. Si pasa de 7.0 a 8.2 no le va a causar ningún problema
P. Durante el laboratorio ¿Por qué agregó en la línea de comandos dos veces el puerto traducido?
R. Si está hablando del primero, recordemos que el ASA va a recibir el tráfico en un puerto en la interfaz del outside y él debe ser capaz de re-direccionarlo a la interfaz interna en el puerto que se especifique. Si se refiere al primer caso, donde tenemos un servidor HTTP, el ASA va a recibir tráfico por el puerto 80 en una IP específica pero él debe ser capaz de direccionarlo a otra IP específica por el puerto 80. Es por eso que se emplean los dos puertos 80, uno en el outside y otro en la red interna
P. En una parte de la exposicion mencionaste interfaces menores y mayores ¿con esto te refieres a los niveles de seguridad?
R. Sí, por ejemplo la interfaz del outside, si le ponemos el nombre outside siempre va a tomar un nivel de seguridad cero mientras que si le ponemos inside va a tomar un nivel de seguridad 100. Por ende se determina que el tráfico del outside al inside no es permitido, se necesita una lista de acceso
P. ¿El orden de los NATs tiene importancia? es decir así como en lo es en las ACLs
R. Sí, por eso se hizo énfasis en lo que es el orden y las prioridades. Porque si tenemos una regla muy general sobre una regla específica, nunca va a ser tomada en cuenta la específica y como se mostró en el ejemplo del doble NAT, teníamos el NAT para tradicir toda la red interna a la IP de la interfaz y como segunda opción teníamos la traducción de un servidor HTTP a la interfaz del outside. La segunda opción nunca va a ser tomada en cuenta porque todo el tráfico interno iba a ser traducido de forma dinámica porque el ASA revisa las reglas de NAT en orden y en ese orden tomaba presencia la regla dinámica con énfasis más general. Entonces, tratar de poner las reglas específicas en primero
P. ¿Qué pasa si ambas rutas fallan?
R. Ahí sí tendríamos un problema porque no tendría ninguna salida a Internet, por eso se recomienda el uso de dos ISP's. Si te fallan dos ISP's al mismo tiempo sería una catástrofe. Muy poco probable
P. En la versión 8.3 en la VPN ¿el nat exempt se modificó?
R. Es el mismo sentido, la configuración sí cambia, se utiliza un doble NAT donde se hace un NAT de identidad, o sea no se traduce, cuando el destino sea la oficina remota. El énfasis no cambia, lo que cambia es la configuración
P. ¿Por qué recomiendas usar la versión 8.3 en la configuración de los NAT's?
R. Si ustedes quieren avanzar, ir hacia el futuro, tener nuevas funcionalidades entonces necesitan 8.3 o algo más nuevo. El ASA es un dispositivo muy poderoso que provee mucha seguridad, es excelente. Si queremos sacarle provecho a este dispositivo debemos de tener la última versión. En este momento, incluso, se habla de 9.0. Entonces, si estamos en 8.0 ya estamos muy atrás
P. En un quipo ASA 5540 Version 8.2 estoy haciendo una VPN LAN to LAN, un lado necesitan verme con IP pública y esta debe ir en túnel VPN y yo lo q tengo es una privada ¿Cómo se realizaría el NAT y la criptación de la IP pública?
R. Se crea una Policy Nat recordando que se necesitan tres cosas: la lista de acceso, que va a identificar el tráfico de tu red interna hacia tu oficina remota; se agrega el NAT, por ejemplo le podemos poner NAT1 y la lista de acceso, y finalmente ponemos Global1 y la interfaz pública. El ASA va a encriptar los paquetes utilizando la IP pública.
P. ¿Por qué debo apuntar a la IP real o privada de los dispositivios internos y no a la pública en las listas de accesso?
R. Esto es cuando el tráfico se recibe desde el outside hacia la red interna. El orden de operaciones en 8.3 es totalmente diferente, debe apuntarse siempre a la IP destraducida luego del NAT. Por ejemplo, si tenemos un servidor interno y queremos traducirlo a una IP específica en el outside, cuando el paquete arribe al interfaz del outside, el ASA va a realizar ahora primero el NAT y el paquete destraducido va a tener la IP pública de quien inició la conexión y la IP privada del host interno la cual debe de enviar la información. Luego de eso es que él va a revisar la lista de acceso. Es por lo anterior que debe de apuntar a la IP privada, si apuntamos a la IP pública del ASA el paquete nunca va a ser transmitido porque ese paquete no se está viendo, sólo se ve el paquete con la IP privada.
P. ¿Cuándo el ASA va soportar IP secundaria?
R. No hay una fecha específica para lanzar dicho funcionamiento ya que tenemos métodos de redundancia como el SLA o el failover en redundancia de dispositivos, lo cual nos permite un funcionamiento similar
P. ¿ Por qué recomiendas la versión 8.3 y no la 8.4?
R. La presentación está enfocada hacia los cambios que tuvo 8.3 y versiones superiores; si he de recomendar alguna, siempre diré que vayan a la más nueva
P. ¿Es cierto que el ASA pierde la capacidad de realizar Proxy-Arp en las últimas versiones?
R. Es correcto, a partir de 8.4.2, el ASA deja de responder a IP's que no están asociadas a la interfaz donde está el NAT. Ésto debido a que se había determinado en diferentes pruebas que exijían vulnerabilidades. Se puede encontrar una forma de solucionarlo: puedes decirle al ISP que te enrute el tráfico a x IP hacia nuestro ASA, de esta manera el ASA siempre va a recibir los paquetes
P. ¿Si la ruta primaria vuelve a estar activa, realiza de inmediato el cambio o debo esperar?
R. Debe ser inmediato del cambio. Tan pronto como se termine el proceso de SLA y el objeto conteste por la vía primaria
P. ¿Puedo redistribuir tráfico basado en la ruta primaria y secundaria?
R. No, redistribución de carga no es soportado en el ASA
P. ¿La NAT dinámica es bidireccioneal?
R. No, la NAT dinámica no es bidireccional, sólo trabaja de manera unidireccional, la NAT estática sí es bidireccional en el direccionamiento de puertos y en la conexión de una dirección IP a otro dirección IP
P. ¿Qué es el Proxy ARP?
R. El Proxy ARP es la capacidad que tiene el ASA para responder por IP's que no están asociadas a su interfaz
P. ¿Cuánto dura SLA en ocurrir?
R. Eso depende de la configuración; si configuramos tres paquetes, entonces después de los tres paquetes el proceso va a terminar. Además, influye el tiempo del timeout, que es el tiempo en el cual se espera y no se recibe respuesta