Consejo

¿Cómo probar un firewall? Una guía de tres pasos para evaluar firewalls

Una cosa que he aprendido probando los últimos productos de firewall: No crea en todo lo que los vendedores aseguran antes de haberlo comprobado usted mismo. Esto significa que "debería funcionar" o "antes funcionaba" podría cambiar a "no funciona en absoluto", o puede que el producto no se comporte como usted esperaba.

No pruebe el rendimiento en mil escenarios diferentes, porque su red sólo tiene un escenario: la realidad. Trate de construir un pequeño conjunto de escenarios que representen su red y su uso.

En este artículo voy a hablar de cómo probar un firewall, incluyendo los tres tipos de pruebas de firewall debería realizar y los tipos que, sorprendentemente, no son necesarios para garantizar la elección del mejor cortafuegos para su organización.

El proceso de prueba de firewall puede dividirse en tres fases concretas: la evaluación subjetiva, la eficacia (efectividad) en la mitigación de amenazas y las pruebas de rendimiento.

Prueba del firewall: Evaluación subjetiva

Su evaluación subjetiva debería estar basada en una lista de criterios, y no en una lista de características. Observe cada parte del firewall, por ejemplo, cómo se definen las reglas, cómo se construyen las VPN, cómo funciona el acceso remoto y si la mitigación de amenazas está a capas encima del producto. Documente sus hallazgos y acompañe las notas con un montón de capturas de pantalla. 

De lo contrario, lo que parece obvio cuando se está probando Firewall A será confuso cuando vuelva a visitar esos resultados mientras estudia Firewall G, seis semanas después. Tome notas sobre cada criterio que esté evaluando.

Una vez que haya evaluado todos los firewalls que esté considerando, realice un "barrido horizontal" que resuma todos los productos según cada criterio. Eso hará que sea fácil asignar puntuaciones y obtener una conclusión objetiva.

Probando firewalls: Pruebas de eficacia

Las pruebas de eficacia son difíciles de hacer sin herramientas especializadas, e incluso si usted tiene las herramientas especializadas, puede que no obtenga buenos resultados. Las pruebas de eficacia deben centrarse en tres áreas: prevención de intrusiones, anti-malware e identificación de aplicaciones.

Para probar la prevención de intrusiones en el sistema (IPS), mi empresa utiliza productos de Mu Dynamics Inc., aunque los vendedores de otras herramientas de pruebas, tales como Spirent Communications plc y IXIA Inc., tienen productos similares. Usted puede comprar o alquilar estas herramientas si lo desea, pero debería poder pedir a cada proveedor de firewall que ejecute las pruebas que usted especifique, ya que suelen tener las mismas herramientas.

Para probar el antimalware y la identificación de aplicaciones, no es posible hacer una prueba de eficacia. En su lugar, haga pruebas puntuales en escenarios con clientes reales que estén descargando virus reales o comunicándose con aplicaciones reales. Una buena forma de descubrir virus recientes es la cuarentena en la puerta de enlace de su correo. Si su software de antivirus pone los virus en cuarentena en un lugar central, ese es otro buen lugar donde buscar. 

Cuando prueba la eficacia del antivirus, intente su propia evasión: HTTP y HTTPS en puertos no estándar, cifrado SMTP e IMAP, y túneles proxy son todos buenos tipos de evasión a añadir a las pruebas de HTTP / HTTPS.

Para la prueba de identificación de la aplicación, elija las aplicaciones que más le interesan y pruébelas con servidores reales. Si desea bloquear la transferencia de archivos tipo peer-to-peer, ejecute algunos clientes de torrentes y vea qué pasa. 

Haga lo mismo para aplicaciones tales como correo web o Facebook, que son los principales candidatos para la identificación y control de aplicaciones. No trate de usar una herramienta de pruebas automatizada, ya que los resultados no son nunca tan precisos como los obtenidos con la aplicación real cuando se comunica con servidores reales. Esto es especialmente cierto de las aplicaciones que son evasivas, tales como Skype y BitTorrent, que nunca pueden ser perfectamente simuladas en una herramienta de prueba.

Prueba de firewalls: Evaluación del rendimiento

Las pruebas de rendimiento también suelen requerir herramientas especializadas, pero se han vuelto tan populares que hay alternativas de código abierto. Al probar el rendimiento, recuerde revisar su banco de pruebas contra un dispositivo nulo; un enrutador o un patch cable  deberían funcionar. Esto le dirá la velocidad máxima de su banco de pruebas. 

A partir de ahí, tenga en mente las leyes de prueba de David Newman: Deben ser repetibles, estresantes (¡para el dispositivo, no para usted!), y significativas. Lleve el dispositivo que está probando a sus límites, incluso si usted no anticipa ir tan lejos. Esto le mostrará dónde se chocaría contra un muro en el futuro y dónde tiene suficiente espacio libre para crecer.

No pruebe el rendimiento en mil escenarios diferentes porque su red tiene sólo un escenario: la realidad. Trate de construir un pequeño conjunto de escenarios que representen su red y su uso, y haga pruebas en un conjunto igualmente pequeño de configuraciones de los firewalls. 

Como la mayoría de los firewalls hacen la mayor parte de su trabajo al manejar tráficos HTTP y HTTPS, puede concentrarse en eso con seguridad. Agregando ese extra 3% aproximadamente de DNS hace las cosas mucho más complicadas y por lo general no le mostrará nada útil.

Las pruebas de rendimiento tienen que ir acompañadas de indicadores de "pasa/falla". Por ejemplo, cuando el firewall empieza a negarse a abrir nuevas sesiones, la prueba debería terminar, porque habrá ha ido más allá de sus límites. También debería establecer otros límites, como el máximo tiempo de latencia, para definir cuándo el firewall no se comporta aceptablemente.

Con estos tres tipos de pruebas completadas, usted tendrá un conocimiento sólido de los mejores productos de firewall para su organización.

Sobre el autor: Joel Snyder es socio sénior de la firma de consultoría Opus One en Tucson, Arizona.

Esto fue publicado por primera vez en noviembre 2012