12 diciembre 2011

Análisis de seguridad de un proxy web

Recientemente he tenido que comprobar la configuración de seguridad de un proxy web de filtrado de contenidos, intentando localizar posibles problemas y vías de mejora. Como no me sonaba que hubiera nada escrito o desarrollado para esto, he creado una batería de pruebas y una página web para automatizar el proceso y pueda servirme en otras ocasiones o a otras personas.

El checklist de pruebas lo he dejado público en una hoja de googledocs y está pensado tanto para verificar la calidad de la categorización de URLs, sus funcionalidades contra el malware, así como otras características de seguridad como son el DLP o el comportamiento con SSL, dividiéndolas en apartados. Algunas de las pruebas se podrán hacer en caja negra y para el resto será necesario consultar la configuración y manual o entrevistar al administrador.

En concreto:
  1. Algunas URL por categorías típicamente susceptibles de ser filtradas: webmails, redes sociales, chats, contenido para adultos, spyware, páginas de hacking, etcétera. Tan solo hay unas cuantas de muestra, algunas muy populares y otras mucho menos para ver el comportamiento.
  2. ActiveX y Applets de java que ejecutan comandos del sistema, sacados del iKat.
  3. Comprobación del navegador que se está usando
  4. Distintos tipos de ficheros comprimidos con malware, exploits, contraseñas, etcétera generados con metasploit.
  5. Malware, herramientas de hacking y mensajes de advertencia.
  6. Documentos ofimáticos con macros y exploits.
  7. Varios PDFs con exploits.
  8. Ficheros de malware con extensiones dobles o incorrectas.
  9. Binarios empacados, sin firma o con firma incorrecta.
  10. Envío de documentos ofimáticos de distintos tamaños, comprimidos, con contraseña.
  11. SSL, túneles para saltarse el proxy tipo CONNECT o páginas de anonimato tipo glype por HTTPS
  12. Túneles vía cgis, conexiones a puertos distintos del 80
  13. Conexión con usuarios fuera del dominio, tipo de autenticación, roles de administración.
  14. Registro de eventos para malware, envío remoto, uso de servidor de fecha y hora.
  15. Opciones de disponibilidad, configuración y copias de seguridad.


En cuanto a la aplicación, se basa en hacer una petición del favicon.ico de los dominios y comprobar si carga o no con javascript, por cierto, ¡gracias a WiredRat por la ayuda!. ¡Ojo! Internet Explorer no carga el favicon.ico si el content-type del icono es texto, por lo que en algunos dominios he metido un link al logo que con el tiempo irán quedando obsoletos y habrá que actualizar.

En otros casos, son un pack de exploits o archivos comprimidos, comprimidos con contraseñas, herramientas de hacking o un formulario para subir ficheros con el objetivo de ir haciendo los tests.

Página web tiene este aspecto:


Durante un par de semanas dejaré online una prueba en este link,  pero será eliminado pasado este tiempo.

Los archivos de la web para modificarlo y montarlo donde queráis están en nuestro repositorio de google code: 


7 comments :

Román Ramírez dijo...

Leyendo tu post, que me parece especialmente interesante, una cosa que echo de menos en los proxy es que los usuarios de este tipo de servicio pudieran proponer una url para ser bloqueada.

Lo habitual es que puedan solicitar que se les abra y casi todas las tecnologías lo soportan. Pero si, de alguna manera, pudieran en un formulario añadir urls tendrías una especie de red de "inteligencia" proponiendo urls.

Es algo que habría que analizar con calma, puesto que habría intentos de "censuras" o gracias. Pero oye, la Wikipedia y las RBL parece que funcionan ;)

No sé qué opinas sobre ello.

Pedro Laguna dijo...

Muy interesante!!! De ponerle estrellita, +1, "like" y todas esas cosas 2.0. 
Una idea de mejora: ademas de mirar el nombre del dominio estaria bien hacer la prueba tambien con la IP. Alguna vez me he encontrado con algun filtro cutre que solo bloqueaba por nombre de dominio...

Alejandro Ramos dijo...

Gracias por tu comentario Román!

Me parece una buena idea, pero considero que es algo que debe estar contemplado en la categorización de urls del propio proxy y su motor. Si un usuario tiene que reportarlas como malas, es que hay alguien que no hace su trabajo como debe. Yo no delegaría algo tan crítico sobre los usuarios.
Aún así, algunas compañias permiten hacer esto mismo en formularios en su propia página web y no desde el proxy como tal...

Alejandro Ramos dijo...

Puede ser una opción, pero imagino que no se hace porque infraestructuras grandes como un Facebook, Twitter o MSN usan redes de cache como akamai que no pueden ser filtradas por IP, no por el número si no por las bajas colaterales que tendrías de otros sitios permitidos.

Gracias por el +1!! :-)

jilmor dijo...

Proxy de la empresa probado! 
Muy buen trabajo :)

Juan Pedro Escalona Rueda dijo...

Siempre te puedes encontrar como el caso del proxy-caché de la Junta de Andalucía, que directamente bloqueaba cierto distribuidor de contenidos porque algún día albergó "algo" de pornografía ;)

Jlkjkj dijo...

el link de pornhub dot com se muestra como link abierto xD!!! fail.