Virtual Patching en funcionamiento (Parte II)

Siguiendo la entrada anterior Virtual Patching en funcionamiento (Parte I) vamos a seguir viendo los efectos del Virtual Patching pero en el caso frente a un escáner de vulnerabilidades.

Lo que vamos a hacer es lanzar uno desde una máquina virtual con Kali Linux hacia un Windows XP vulnerable. ¿Por qué un XP? Porque este sistema operativo está aún muy presente en muchos equipos en entornos industriales y debido al largo ciclo de vida de las estaciones o instalaciones que gobiernan, siguen funcionando a pleno rendimiento. Sin embargo, como sabemos ya no hay soporte y muchos de ellos no están parcheados, lo cual les convierte en un objetivo muy apetecible a malware y usuarios malintencionados. Ni qué hablar de Windows 2000 que también los he visto… Buenos, el esquema era el siguiente:

Esquema 01

Como decía, en el post anterior trataba los resultados tras hacer un escaneo con Nmap. Ahora toca pasar a la siguiente etapa dentro de una supuesta intrusión, o auditoría. Encontrar vulnerabilidades para ser explotadas. Para ello se utiliza un escáner que en nuestro será “Nessus”, pudiendo encontrarse otros como OpenVAS y Nexpose.

Kali Linux no lo trae por defecto, así que lo hemos descargado de la página del producto, obtenido el código correspondiente, instalado y actualizado los plugins. Luego creamos el proyecto y definimos los perfiles que queremos utilizar. En mi caso he dejado sólo los relacionados con plataformas Windows para que sea algo más rápido. No obstante os dejo otro de mis post donde hablaba de la metodología del Pentesting. Lo podéis encontrar aquí.

Nessus 01

Por otro lado la configuración de reglas en el Fortinet Fortigate Rugged 60D quedaría como sigue:

Nessus 02

Como se puede ver se permite todo el tráfico entre las interfaces “Wan1” y “Wan2”, pero se someterá a los motores Antivirus, Control de Aplicación e IDS/IPS. Lo sé, lo sé, habría que restringir el tráfico sólo al imprescindible pero para la prueba lo dejaré así. En la vida real, ni se os ocurra hacer esto. En el caso de este último, el IDS, se ha configurado para que bloquee “Block” todo aquél tráfico que coincida con alguna de las reglas en él definidas.

Tras lanzar el escáner vemos que el resultado es el siguiente. El Fortigate ha bloqueado los paquetes desde el escáner:Nessus 03

Si a continuación hacemos un reporte de las vulnerabilidades encontradas vemos que sólo se han encontrado un total de 8 de nivel informativo.

Nessus 04

Así pues el supuesto atacante apenas podría haber obtenido información del objetivo, con lo que tendría más complicado a la hora de lanzar un exploit concreto cara a aprovechar una vulnerabilidad. Aunque no se aprecie en la imagen, los datos ofrecidos no son relevantes cara a este fin, la intrusión. En cambio, si deshabilitamos dicha protección, esto es:

Nessus 05

Y lanzamos de nuevo el escáner, el resultado sería bien distinto:

Nessus 06

Aquí veremos que sí se obtienen datos sobre el equipo con Windows XP y por tanto sería exitoso el ataque como el que se podría llevar a cabo en el punto siguiente. Entre ellas hay un total de 3 vulnerabilidades “Critical”, 2 “Medium”, y 20 “Info” destacando entre ellas la que figura a continuación.

34477 (1) – MS08-067: Microsoft Windows Server Service Crafted RPC Request Handling Remote 

Code Execution (958644) (uncredentialed check) 

Synopsis

Arbitrary code can be executed on the remote host due to a flaw in the ‘Server’ service.

Description

The remote host is vulnerable to a buffer overrun in the ‘Server’

service that may allow an attacker to execute arbitrary code on the remote host with the ‘System’ privileges.

See Also

http://technet.microsoft.com/en-us/security/bulletin/ms08-067

Solution

Microsoft has released a set of patches for Windows 2000, XP, 2003, Vista and 2008.

Risk Factor

Critical

CVSS Base Score

10.0 (CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C)

CVSS Temporal Score

8.7 (CVSS2#E:H/RL:OF/RC:C)

STIG SeverityI

References 

BID 31874

CVE CVE-2008-4250

XREF OSVDB:49243

XREF MSFT:MS08-067

XREF IAVA:2008-A-0081

XREF CWE:94

Exploitable with

CANVAS (true)Core Impact (true)Metasploit (true)

Plugin Information:

Publication date: 2008/10/23, Modification date: 2015/06/18

Hosts

XX.XX.XX.17 (tcp/445)

Queda bastante claro la funcionalidad de estos motores. A pesar de no restringir el tráfico mediante reglas de firewall tradicionales y dejar pasar todo, algo que obviamente NO DEBE HACERSE BAJO NINGÚN CONCEPTO, nos proporcionan un grado de protección evidente.

En este ejemplo lo hemos hecho sobre un Windows XP vulnerable, pero esto también podríamos emplearlo como elemento de seguridad perimetral sobre Sistemas de Control y Automatización Industrial u otros dispositivos con capacidades limitadas para la implementación de medidas de seguridad. Su protección en este caso radicaría en el Fortigate Rugged 60.

Así hemos terminado por hoy. En la próxima entrada veremos cómo comprometer el Windows XP mediante Metaesploit gracias a la vulnerabilidad anterior.

Como en otras ocasiones os animo a que dejéis vuestro comentario, tanto si es positivo como si no lo es. Todo sirve para mejorar.

Lo dicho, un saludo, nos vemos en la próxima!!

Virtual Patching en funcionamiento (Parte I)

Siguiendo con el tema de Virtual Patching ahora toca ver cómo funciona y los beneficios que puede aportarnos.

Para ello he creado un entorno con dos PCs interconectados por medio de un Fortinet Fortigate Rugged 60D configurándolo con motores Antivirus, IDS/IPS y Control de Aplicación. La parte de firewall la he dejado con un “permit any any any” (IP origen, destino y puerto, respectivamente) Hay que recordar que cada una de ellos lo podemos configurar en dos modos, “Monitor” o “Block”. Con el primero, en caso de que se detecte algún patrón que puda quedar recogido dentro de las reglas y firmas, no se tomará ninguna acción, sólo se registrará el evento y se dejará pasar. En cambio con “Block”, valga la redundancia se bloqueará y la amenaza será paralizada.

Luego, estas características han de aplicarse, o no, a las reglas de Firewall en él configuradas.

En cada uno de estos PCs he virtualizado un total de 3 máquinas.

Una con Kali Linux desde la cual simularemos la actividad de un atacante. Lanzaremos un escaneo de puertos con Nmap, escáner de vulnerabilidades con Nessus, intento de intrusión con Metaesploit y Armitage y por último copiar en un recurso de red el fichero EICAR.

Otra con un Windows XP vulnerable, el objetivo. Se ha elegido este ya que posee vulnerabilidades que para un ejemplo pueden ser fácilmente explotables. Aparte porque su uso en entornos industriales y o vida prolongada es aún bastante común.

Por último un Fortinet FotiManager con funciones FortiAnalyzer desde donde gestionaremos el equipo Fortigate Rugged 60D. Lo he querido utilizar ya que con un despliegue de varios equipos resulta aconsejable no sólo por la gestión centralizada sino porque nos permite almacenar los logs, analizar tráfico, sacar informes, ver registros, etc.

Todo queda resumido de la siguiente manera:

 

Esquema 01

En la imagen siguiente se muestra cómo el equipo Fortigate bloquea un total de 9965 amenazas catalogadas en un total de 1993 incidentes, provenientes de la IP XX.XX.XX.15 de la máquina Kali Linux. Esto es debido a que la aplicación Nmap envía sucesivamente paquetes para que en función de las respuestas obtenidas se pueda determinar si un equipo está activo, o no, puertos abiertos; versiones de aplicaciones, servicios; etc.

Para conocer un poco más recomiendo la siguiente lectura, pincha aquí.

Imagen 01

En esta otra se puede ver que el equipo destino tiene la IP XX.XX.XX.17.

Imagen 02

En la siguiente imagen se muestra las “sondas” enviadas desde el equipo Kali Linux identificando alguna aplicación que otra:

Imagen 03

Como se puede apreciar éstas han sido bloqueadas no pudiéndose obtener datos sobre el equipo objetivo, el XP. Esto mitigaría la etapa inicial de recolección de información que un atacante llevaría a cabo y poder, a partir de ahí, realizar otro tipo de acciones sobre nuestros sistemas.

Obviamente habría que configurar las reglas del firewall del modo más restrictivo posible y sobre el tráfico que dejamos pasar aplicar el análisis de los motores Antivirus, IPS y Control de Aplicación. Sin embargo para este ejemplo se ha querido dejar así para ver el comportamiento de la aplicación Nmap y qué es lo que sucede si no empleamos un cortafuego. Pero como como digo, siempre, siempre, siempre, ha de restringirse el tráfico sólo al estrictamente permitido por medio de estos firewalls.

Esto es todo por hoy, pero os debo las siguientes entradas sobre escáner de Vulnerabilidades, Metaesploit y EICAR Test File.

No s vemos en la próxima, y como siempre digo, se agradece cualquier comentario al respecto.

Muchas gracias!

Parches y Virtual Patching

A estas alturas todos tenemos claro que una de las medidas a aplicar dentro de nuestras políticas de seguridad es tener actualizados los sistemas y equipos de red. Esto lo podemos conseguir instalando parches para sistemas operativos, actualización de aplicaciones y versiones de firmware. Esto creo, que a nadie nos pilla por sorpresa.

Quizás uno de los puntos más críticos de las opciones planteadas es aplicar los últimos parches emitidos por el fabricante o los desarrolladores. La instalación de los mismos no debería provocar que nada dejase de funcionar, sin embargo este riesgo no es cero y puede suceder.

En entornos industriales, se emplean PCs para la interacción, configuración y gobierno de la maquinaria, robots y demás sistemas de control y automatización. Como he hablado en otras ocasiones aquí la premisa es la disponibilidad de las instalaciones, y por tanto, las posibles causas que puedan provocar una interrupción del servicio deben quedar reducidas al máximo. Para ello es necesario, o al menos conveniente, tener un entorno de laboratorio para el testeo de parches, ver su comportamiento y una vez comprobada la ausencia de anomalías, proceder a su despliegue siempre de forma progresiva.

Así pues se nos plantean 3 posibles casuísticas:

Hasta ahora hemos contemplado que el parcheo se puede llevar a cabo, sin embargo esto no siempre es así. Imaginemos que adquirimos un equipamiento a un proveedor. Éste garantizará su funcionamiento en esas condiciones, no en cambio, si sobre ella se realiza algún tipo de instalación de parches o software adicional. Seguramente será posible la contratación de un soporte de mantenimiento pero a cambio, posiblemente, de una muy considerable cantidad económica. Así pues el escenario, muy probablemente, será no parchear. Con lo que ello conlleva, claro.

Como segundo caso, debemos recordar que una de las características de los equipos industriales es su ciclo de vida prolongado. Éste es muy superior a los dispositivos IT convencionales, sin embargo no dejan de pertenecer a este ámbito por muy PCs industriales que sean. Llevan en sus entrañas Windows 2000, XP, 7, etc. Eso por no citar a NT que aún los sigo viendo. Estas versiones hasta XP, están fuera de soporte, aunque su uso sigue y seguirá vigente por varios años más. Y en estos casos, ¿cómo parcheamos si no tenemos soporte?

Finalmente podría darse que bien por su criticidad o por su delicadeza, no nos atrevamos a “meter mano” a este equipo que lleva sin tocarse 3, 4, 5 o más años. No nos podemos arriesgar a que surja algún inconveniente y no sepamos resolverlo. Y claro, ¿qué hacemos entonces? ¿Asumimos los riesgos? ¿O no?

En cualquier caso, la no actualización de nuestros equipos conlleva un riesgo. Quedan expuestos a una mayor probabilidad que un ataque, intrusión o actividad de malware, tenga éxito. Los entornos industriales, hasta hace relativamente poco, eran redes que permanecían aisladas del resto y su acceso era muy limitado. Con la integración en redes Ethernet, funcionalidades basadas en TCP/IP y la aparición del IIoT, esta exposición está siendo mayor y por tanto a los riesgos han aumentado.

Claro y ¿qué hacer entonces? Buena pregunta.

Pues bien, una de las opciones viene de la mano del Parcheo Virtual o Virtual Patching.

¿Qué esto de Virtual Patching? Podríamos definirlo como la política de seguridad destinada a prevenir la explotación de una vulnerabilidad mediante el análisis del tráfico, sometiéndolo a distintas capas de seguridad con el fin de evitar que código malicioso alcance la aplicación o sistema vulnerable. Esto es, el “ataque” se bloquea antes de que llegue al objetivo. Dichas capas vienen dadas por motores Cortafuegos, Antivirus, IDS/IPS, Control de Aplicaciones y Filtrado de Tráfico Web.

Como viene siendo habitual no voy a referirme a los entornos IT, sino a los industriales. Ya en la entrada anterior “Convertidores de medios” hablaba de la necesidad de utilizar dispositivos diseñados y pensados para ese fin, y la de hoy no es para menos.

Un ejemplo lo encontramos en el Fortinet Fortigate Rugged 60D, cuyas especificaciones las podéis encontrar aqui. Y su Quick Start Guide aquiForti

Este equipo es lo que podemos denominar UTM (Unified Threat Management) pero orientado a entornos industriales.

Como podemos ver, ya con su aspecto, las diferencias con los dispositivos tradicionales IT son bastante evidentes, el diseño ruguerizado lo delata. Otra de ellas es la implementación de protocolos industriales como Modbus, Profinet, OPC, DNP3, etc. Luego sobre ellos podemos aplicar las firmas de Control de Aplicación e IPS.

Por otra parte tendremos la posibilidad de instalación sobre carriles DIN, un modo de instalación de equipos industriales en armarios destinados a tal fin. Igual modo la alimentación eléctrica, por medio de borneros pudiendo emplear además la fuente de alimentación convencional que trae consigo.

En adición a lo anterior, podremos ver que la temperatura operacional va de -20 a 70 º C. ¿os imagináis las temperaturas más bajas y altas en un entorno IT convencional? Ufff qué frío y que calor…

Para su configuración inicial, nos descargaremos el software Fortiexplorer. Luego con el cable USB que viene de serie, conectaremos nuestro PC con el dispositivo.

Allí podremos acceder al Dashboard donde asignaremos algunos parámetros básicos y visualización de cierta información.

Luego dentro del apartado “Config -> Features”, definiremos aquellas características que queramos activar.

Imagen 01

Imagen 02

Imagen 03

A destacar su modo de funcionamiento denominado “Transparente”. Es modo convierte al dispostivo como un Firewall pero a nivel de Capa 2. No es necesario realizar ningún cambio en el direccionamiento IP del equipo a proteger. Sólo bastaría asignar una IP de gestión del mismo rango que éste.

Imagen 04

En “Security Profiles” definiremos los perfiles de configuración para los motores Antivirus, Filtrado Web, Control de Aplicación e IPS, en base a firmas y reglas.

Imagen 05

Imagen 06

En cada uno de ellos podremos definir si en caso de detectar comportamientos coincidentes con cada motor, entre “Block” y “Monitor”. Esto es, tomar una medida y bloquearla; o bien dejarla pasar, monitorizarla, registrando el evento como un log. Para ello deberemos indicar el servidor dónde enviar los datos. Fortinet tiene las herramientas propietarias FotiManager para una administración centralizada de dispositivos y FortiAnalyzer, para el análisis del tráfico y logs.

Imagen 07

El dispositivo tiene otras muchos parámetros y funcionalidades a las que podríamos dedicar horas y horas. No obstante en el futuro, espero poder subir alguna más. Todo depende del tiempo disponible.

Por ahora ya hemos terminado con esta, y como siempre, os pido que dejéis vuestra opinión a modo de comentario de lo que os ha parecido, tanto si os ha resultado, o no, interesante, o cualquier otro crítica constructiva.

Lo dicho, muchas gracias, nos vemos en la siguiente!!

 

Pfsense

Hola de nuevo. En esta ocasión os dejo una serie de entradas del blog Security Art Work de S2 Grupo.

Las mismas hablan de las distintas funcionalidades del Firewall Pfsense. No os voy a dar más detalles ya que está todo muy bien explicado. Excelentes artículos de tantos que podréis encontrar en este blog, y que invito a seguir.

Parte I

Parte II

Parte III

Parte IV

Parte V

Parte VI

Espero que os gusten!!

 

Primeros pasos con Comware

Hola de nuevo. Vamos con otra entrada, esta vez sobre cómo configurar equipos de redes. Sin embrago, no me voy a meter con Cisco sino con HP. HP tiene un área de Networking donde tienen una gama de productos para distintos ámbitos, Data Center, Acceso, Servidores, etc. Inicialmente HP tenía su línea de equipos denominándose Procurve. Sin embargo, en 2010 compra la empresa 3Com, que a su vez en 2007 compra H3C. H3C a su vez era lo que conoce como “joint venture” entre 3Com y Huaweii.

Actualmente podríamos resumir la gama de equipamiento de la siguiente manera:

Portfolio switches

En mi caso me está tocando pegarme con los de la serie A que viene con el sistema operativo Comware, vamos lo que vendría a ser la IOS de los Cisco. También podremos encontrarnos con equipos, esta vez de la serie E, que vengan con Provision, otro sistema operativo.

Existe en la web una guía comparativa entre los comandos de los tres sistemas operativos que podréis encontrar aqui.

No obstante utilizando encontraremos más de una similitud entre Comware e IOS, lo cual nos llevará en muchas ocasiones a confusión especialmente se venimos del mundo Cisco. Pero bueno, es lo que hay.

Empecemos pues.

EL equipo en el que voy a hacer las configuraciones es un HP A3600 Series con una versión de software Comware 5.2. Me conectaré por consola, siendo los valores por defecto:

9600 bps

8 bits de datos

Sin paridad

1 bit de parada

Sin control de flujo.

Una vez arrancado el equipo entraremos directamente al equipo sin autenticación ni nada. Veremos que el prompt del switch nos aparecerá como entre signos de menor y mayor que, estos:

<HP>

Los switches HP tiene dos vistas. Al arrancar el equipo ey ver el prompt tal y como lo he puesto con anterioridad, estaremos en la vista de usuario, user-view. Esta es una vista en la que se realizan operciones sobre la memoria flash; listar, renombrar o borrar ficheros; salvar configuraciones, etc. Para poder entrar a configurar el equipo en si mismo como VLANs, puertos, IPs, etc. deberemos entrar en lo que se denomina system-view. Para ello deberemos ejecutar:

Ahora podremos ver que los símbolos “< >” han cambiado “[ ]”. Ahora sí que podremos entrar configurar el equipo.

Otros aspectos a tener en cuenta es que a diferencia de Cisco IOS que puede haber hasta 15 niveles, Comware sólo tiene 4, lo cual simplifica mucho la cosa. Estos niveles son:

Visitor                 0

Monitor              1

System                2

Manager             3

Cada nivel estará autorizado a ejecutar una serie de comandos.

El nivel Visitor, incluye herramientas de diagnóstico típicas como ping y traceroute, sin embargo no está permito salvar la configuración.

El nivel Monitor, incluye los comandos display y debugging los cuales pueden ser usados para tareas de diagnóstico y mantenimiento. Aquí tampoco está permitido guardar configuraciones.

El nivel System, incluye comandos como los de routing y para las distintas capas de red y está orientado proporcionar servicios de red al usuario.

El nivel Manager, es el nivel más alto y con él se podrán realizar los ajustes de la configuración del equipo.

Lo primero que haremos será asignar una contraseña a la línea de comandos y el acceso remoto vía SSH.

Configuraremos una contraseña para el usuario de nivel 3:

[HP]super password level 3 cipher p4ssw0rd 

Configuramos el puerto de consola, en HP “aux 0”, indicándole que el modo de autenticación es “password” y que la contraseña será “4uxp0rt”

[HP]user-interface aux 0

[HP-ui-aux0]authentication-mode password

[HP-ui-aux0]set authentication password cipher 4uxp0rt

[HP-ui-aux0] 

Hecho esto ya tendríamos configurada una contraseña si nos conectásemos por el puerto de consola. Ahora pasamos configurar el acceso por SSH.

Habilitamos el acceso por SSH.

HP]ssh server enable

Info: Enable SSH server. 

Generamos la contraseña RSA. Aqui nos aparece que ya teneemos una porque ya la había generado con anterioridad.

 [HP]public-key local create rsa

Warning: The local key pair already exist.

Confirm to replace them? [Y/N]:Y

The range of public key size is (512 ~ 2048).

NOTES: If the key modulus is greater than 512,

It will take a few minutes.

Press CTRL+C to abort.

Input the bits of the modulus[default = 1024]:

Generating Keys…

++++++

++++++

+++

+++

Ahora creamos un usuario local “netadmins”. Le autorizaremos a emplear SSH y su contraseña será n3t4dm1ns:

 [HP]local-user netadmins

New local user added.

 [HP-luser-netadmins]service-type ssh

 [HP-luser-netadmins]password cipher n3t4dm1ns

 [HP-luser-netadmins]

Ahora pasaremos a definir una IP al equipo. Por defecto está definida la VLAN 1 al igual que en los equipos Cisco.

[HP]interface Vlan-interface 1

 [HP-Vlan-interface1]ip address 192.168.10.10 24 

Finalmente deberemos configurar las interfaces virtuales. Ahí le diremos que el modo de autenticación será “scheme”, esto es por usuario y contraseña y que el protocolo que lo utilizará será SSH.

[HP]user-interface vty 0 4 

[HP-ui-vty0-4]authentication-mode scheme

 [HP-ui-vty0-4]protocol inbound ssh

Y ahora guardamos la configuración

[HP-ui-vty0-4]save

The current configuration will be written to the device. Are you sure? [Y/N]:Y

Please input the file name(*.cfg)[flash:/config.cfg]

(To leave the existing filename unchanged, press the enter key):

flash:/config.cfg exists, overwrite? [Y/N]:Y

Validating file. Please wait….

The current configuration is saved to the active main board successfully.

Configuration is saved to device successfully.

[HP-ui-vty0-4]

Y así ya tendríamos configurado de una manera básica nuestro switch de HP. A continuación os dejo la captura con el login.

Login SSH_03

Al abrir la sesión con SSH nos logueamos con el usuario y contraseña de “netadmins”. Luego tenemos que escalar privilegios con el somando “Super 3” para acceder a administrar el equipo. Ahí tendremos que meter la correspondiente contraseña. Luego con “system-view” accederemos al resto de opciones.

Como decía, de  esta manera ya tendríamos configurado el switch. Ahora a seguir con el resto de configuraciones…

ACLs, Listas de Control de Acceso

Siguiendo el hilo de la entrada anterior, “Cuando las VLANs y Firewall no son suficientes” vamos hablar de las ACL, Access Control List o Listas de Control de Acceso.

¿Qué son?

Una Lista de Control de Acceso es un conjunto de sentencias que permiten o deniegan un tráfico determinado. Algo similar a lo que viene hacer un cortafuegos.

¿Para qué se utilizan?

Aunque pueden tener diversos usos, es una manera “sencilla” de filtrar el tráfico que pasa por un dispositivo de red de capa 3, o también para el acceso al mismo vía SSH. Es útil para aplicar ciertas políticas de seguridad.

¿Qué tipos hay?

Hay varios tipos, pero poniendo como ejemplo los dispositivos Cisco, las más utilizadas son las “Standard” y “Extended”. En las “Standard” emplearemos como parámetro de filtrado las direcciones IP de origen; mientras que las “Extended” utilizaremos la IPs de origen, destino y puertos. También tendremos las “Named”, que es lo mismo que las dos anteriores pero nos permiten asignarlas un nombre en lugar de un número. Más adelante lo explicaremos.

¿Cómo funcionan?

Una Lista de Control de Acceso se compone de una serie de sentencias que permiten o deniegan un tráfico determinado. El equipo irá comparando cada paquete con cada una de las sentencias de la ACL, de la primera a la última. En el momento que un paquete coincida con la sentencia, ésta se ejecuta y no se sigue comparando. Cada ACL tiene un “deny any” implícito al final de las sentencias, esto es, si un paquete no coincide con ninguna de las sentencias se descarta.

¿Cómo se utilizan?

Una vez que la ACL está creada, se debe aplicar a una intefaz, y también en un sentido determinado. Es decir, en sentido entrante (Inbound) o saliente (Outbound) a esa interfaz.

A este respecto debemos tener en cuenta dos aspectos importantes. Cuando una ACL se aplica en sentido entrante, los paquetes que serán evaluados primero por dicha ACL, y en caso de ser permitidos será entonces cuando el equipo los enrute por alguna interfaz de salida. Obviamente, todos los paquetes que se denieguen no serán sometidos a la tabla de enrutamiento.

Sin embargo, cuando una ACL se aplica a en sentido “Saliente”, ésta se aplicará una vez los paquetes hayan sido enrutados. O lo que es lo mismo, primero se enrutan y luego se ve si se permiten o deniegan.

¿Por qué este matiz? Tanto el enrutamiento, como comparar cada paquete con cada sentencia de las ACL son procesos que consumen recursos hardware. Por tanto, deberemos tener en cuenta el sentido ya que si tenemos que descartar paquetes, será mejor hacerlo en ACL entrantes de tal manera que el equipo no tenga que malgastar recursos en enrutarlo para luego descartarlo en caso denegar ese mismo tráfico en una ACL saliente.

Por otro lado, es conveniente crear el contenido de las ACL en un editor de texto y luego aplicarla en el equipo haciendo un “copy/paste”. ¿Por qué? Cada vez que añadamos una sentencia ésta será anexada al final de la ACL y tampoco tendremos la posibilidad de borrar una entrada concreta.

ACLs Standard

Las Listas de Control de Acceso Estándar son aquellas que efectúan el filtrado, permitiendo o denegando inspeccionando la IP de origen. Cada ACL de este tipo lo podremos numerar de un rango que podrá ir de 1-99 o 1300-1999.

Switch01(config)#access-list ?
   <1-99> IP standard access list
   <100-199> IP extended access list
   <1000-1099> IPX SAP access list
   <1100-1199> Extended 48-bit MAC address access list
   <1200-1299> IPX summary address access list
   <1300-1999> IP standard access list (expanded range)
   <200-299> Protocol type-code access list
   <2000-2699> IP extended access list (expanded range)
   <300-399> DECnet access list
   <600-699> Appletalk access list
   <700-799> 48-bit MAC address access list
   <800-899> IPX standard access list
   <900-999> IPX extended access list
    dynamic-extended Extend the dynamic ACL absolute timer
    rate-limit Simple rate-limit specific access list

Definido el número, a continuación deberemos especificar si permitimos o denegamos el tráfico en cuestión.

Switch01(config)#access-list 5 ?
   deny Specify packets to reject
   permit Specify packets to forward
   remark Access list entry comment

El siguiente paso será proporcionar los valores:

Switch01(config)#access-list 5 deny ?
   Hostname or A.B.C.D Address to match
   any Any source host
   host A single host address

La primera de las opciones hace referencia a la IP o rango de éstas. La segunda y la tercera permiten, en lugar de especificar en formato numeral “cualquier IP” o “una IP concreta”, introducir los términos “any” y “host” respectivamente.

Máscaras Wildcard

Las Máscaras Wildcard son utilizadas por las ACLs para indicar un equipo, un conjunto de éstos o una red completa. Se asemeja a lo que vendría ser una máscara de subred aunque con bien significado es distinto.

Cuando en una Máscara Wildcard figura un “0” se entiende que el valor que consta en la IP debe coincidir. Sin embargo cuando aparece un “255” puede tomar cualquier valor. Por ejemplo:

192.168.1.0 0.0.0.255

Quiere decir que los tres primeros octetos “192.168.1” que coincidan con el paquete se les aplicará esa sentencia en la ACL. El cuarto octeto podrá tener cualquier valor, de 1 a 254.

Por ejemplo:

Switch01(config)#access-list 10 deny 192.168.1.0 0.0.0.255 

Esto añadirá una sentencia en la que se denegarán todos los paquetes con IP de origen “192.168.1” ya que la máscara tiene un “0”. El cuarto octeto puede tener cualquier valor “255”, entre 1 y 254.

Para indicar rango de subredes deberemos de realizar cálculos. Una manera sencilla para indicar redes es restar “255” a la máscara de subred de una dirección IP contenida en ese rango.

No os asustéis, aquí os dejo unos enlaces donde una calculadora hará el trabajo por vosotros:

Link 1

Link 2

Os dejo unos enlaces que hablan de las Máscaras Wildcard

Link 1

Link 2

Como dije antes, no sólo tenemos que crear las ACL sino además aplicarlas a una interfaz en alguno de los sentidos, bien entrante, bien saliente. Esto es:

Switch01#config t
Switch01(config)#access-list 10 deny 192.168.1.0 0.0.0.255
Switch01(config)#access-list 5 permit any
Switch01(config)#interface Ethernet 0
Switch01(config-if)#ip access-group 10 out 

En la configuración anterior configuramos la access list “Standard”, número 5, en la que denegaríamos la red 192.168.1.0/24, y luego permitiríamos el resto de tráfico. Luego, aplicaríamos dicha ACL a la interfaz Ethernet 0 en sentido saliente.

ACLs Extended

A diferencia de las ACL Standard, las “Extended”, pueden llevar a cabo el filtrado considerando la IP de origen, la de  destino, y los puertos.

Los rangos para identificar estas ACLs van de 100 a 199 y de 2000 a 2699.

Switch01(config)#access-list 115 ?
   deny Specify packets to reject
   dynamic Specify a DYNAMIC list of PERMITs or DENYs
   permit Specify packets to forward
   remark Access list entry comment

Acto seguido definiremos si denegamos o permitimos:

Switch01(config)#access-list 115 deny ?
   <0-255> An IP protocol number
   ahp Authentication Header Protocol
   eigrp Cisco's EIGRP routing protocol
   esp Encapsulation Security Payload
   gre Cisco's GRE tunneling
   icmp Internet Control Message Protocol
   igmp Internet Gateway Message Protocol
   ip Any Internet Protocol
   ipinip IP in IP tunneling
   nos KA9Q NOS compatible IP over IP tunneling
   ospf OSPF routing protocol
   pcp Payload Compression Protocol
   pim Protocol Independent Multicast
   tcp Transmission Control Protocol
   udp User Datagram Protocol

Ahora definiremos el protocolo:

Switch01(config)#access-list 110 deny tcp ?
   A.B.C.D Source address
   any Any source host
   host A single source host

El siguiente parámetro de definir es la IP, red o subred, o cualquier IP de origen. Cabe mencionar que  podremos indicar el puerto de origen con los parámetros eq, gt, lt, neq o range. Para nuestro ejemplo no consideraremos puertos de origen:

Switch01(config)#access-list 110 deny tcp any ?
   A.B.C.D Destination address
   any Any destination host
   eq Match only packets on a given port number
   gt Match only packets with a greater port number
   host A single destination host
   lt Match only packets with a lower port number
   neq Match only packets not on a given port number
   range Match only packets in the range of port numbers

Como es lógico habrá que especificar la IP, red o subred, o cualquier IP de destino.

Switch01(config)#access-list 110 deny tcp any host 172.16.30.2 ?
   ack Match on the ACK bit
   dscp Match packets with given dscp value
   eq Match only packets on a given port number
   established Match established connections
   fin Match on the FIN bit
   fragments Check non-initial fragments
   gt Match only packets with a greater port number
   log Log matches against this entry
   log-input Log matches against this entry, including input interface
   lt Match only packets with a lower port number
   neq Match only packets not on a given port number
   precedence Match packets with given precedence value
   psh Match on the PSH bit
   range Match only packets in the range of port numbers
   rst Match on the RST bit
   syn Match on the SYN bit
   time-range Specify a time-range
   tos Match packets with given TOS value
   urg Match on the URG bit
   <cr>

Aquí sí que tendremos que definir un puerto de destino o parámetros a tal efecto. Los equipos tienen predefinidos el nombre de los servicios en lugar de los números de puertos para que sea más intuitivo.

Switch01(config)#access-list 110 deny tcp any host 172.16.30.2 eq ?
   <0-65535> Port number
   bgp Border Gateway Protocol (179)
   chargen Character generator (19)
   cmd Remote commands (rcmd, 514)
   daytime Daytime (13)
   discard Discard (9)
   domain Domain Name Service (53)
   drip Dynamic Routing Information Protocol (3949)
   echo Echo (7)
   exec Exec (rsh, 512)
   finger Finger (79)
   ftp File Transfer Protocol (21)
   ftp-data FTP data connections (20)
   gopher Gopher (70)
   hostname NIC hostname server (101)
   ident Ident Protocol (113)
   irc Internet Relay Chat (194)
   klogin Kerberos login (543)
   kshell Kerberos shell (544)
   login Login (rlogin, 513)
   lpd Printer service (515)
   nntp Network News Transport Protocol (119)
   pim-auto-rp PIM Auto-RP (496)
   pop2 Post Office Protocol v2 (109)
   pop3 Post Office Protocol v3 (110)
   smtp Simple Mail Transport Protocol (25)
   sunrpc Sun Remote Procedure Call (111)
   syslog Syslog (514)
   tacacs TAC Access Control System (49)
   talk Talk (517)
   telnet Telnet (23)
   time Time (37)
   uucp Unix-to-Unix Copy Program (540)
   whois Nicname (43)
   www World Wide Web (HTTP, 80)

Pues si lo que queremos es bloquear el Puerto 80, quedaría:

Switch01(config)#access-list 110 deny tcp any host 172.16.30.2 eq 80 log 

Como veréis podremos loguear cada vez que un paquete “machee” con esa sentencia. Eso está bien como control, pero ojo que nos puede inundar de mensajes la consola.

ACL Named

Las ACl Named (Nombradas) son aquellas que en lugar de configurarlas con un número, lo podremos hacer con un nombre para que nos sea más intuitivo. La única diferencia será anteponer el término IP a lo que hemos visto.

Switch01(config)#ip access-list standard BlockSales
Switch01(config-std-nacl)#
Switch01(config-std-nacl)#deny 172.16.40.0 0.0.0.255
Switch01(config-std-nacl)#permit any
Switch01(config-std-nacl)#exit 

Y en lo referente a las ACLs esto es todo. EL tema da para mucho más así que aquí os dejo algún otro enlace para que profundicéis sobre el tema.

Link 1

Link 2

Link 3

Link 4

El objetivo de este artículo ha sido mostrar una funcionalidad que no debemos dejar de pasar de alto para proteger nuestras comunicaciones entre sistemas, equipos y dispositivos. Las ACLs son son uns sustituto de un cortafuegos pero pueden ser un aliado muy, muy bueno.

Espero que os haya gustado.

Un saludo!!!