- Partir de una base segura (implementación inicial de la seguridad en nuestra web)
- Confirmando si existen vulnerabilidades en un script instalado
- La forma directa de buscar vulnerabilidades
- El trabajo de mantenimiento
- Conclusión
Si buscamos en Internet información sobre seguridad para sitios web, encontraremos miles de artículos que abordan temas como sniffers, spoofing, implementaciones de TCP/IP, escaneos de puertos, herramientas de detección de intrusiones, denegación de servicio, etc, etc.
Cuando un webmaster (y no un administrador de sistemas) simplemente quiere aumentar el nivel de seguridad en sus sitios web, toda esta abundancia de información le llevará a plantearse: "OK, todo esto es muy interesante, pero… ¿qué puedo hacer yo para mejorar la seguridad de mis sitios web hoy, sin tener que estudiar todos estos artículos durante meses? Yo no soy el administrador del servidor, y no voy a recompilar el Apache, ni instalar parches al sistema operativo (esas cosas las hace mi empresa de hosting). ¿Hay algo que yo pueda hacer AHORA para hacer que mis sitios web estén más seguros y no sean vulnerables a los hackers?"
Este artículo describe tres medidas de seguridad concretas y sencillas que los webmasters podrán aplicar ya.
Antes de enumerar las medidas concretas que el webmaster puede aplicar por su cuenta para aumentar el nivel de seguridad de sus sitios web, es bueno recordar que el otro 50% de la responsabilidad sobre la seguridad de la web recae en el administrador del servidor (la empresa de hosting).
De modo que si el webmaster cuida al máximo los aspectos de seguridad de su web, pero el hosting no le acompaña en su preocupación, entonces el sistema (servidor + sitio web) seguirá siendo igualmente inseguro. Si por el contrario, la empresa de hosting proporciona los máximos cuidados en cuanto a la seguridad, y es el webmaster quien no lo hace… entonces sus sitios web serán inseguros (y el webmaster tarde o temprano lo sabrá, tal vez de la peor forma).
Qué es lo que introduce vulnerabilidades en un sitio web
El grado de inseguridad que puede presentar un sitio web depende directamente de las funcionalidades que el mismo tenga instaladas. Si el sitio está creado usando simplemente HTML (y en nuestras carpetas sólo tenemos archivos .htm, .html, .css, .jpg y .gif) entonces el peligro será mínimo, y las posibles vulnerabilidades estarán completamente del lado que le toca atender a nuestro proveedor de hosting.
Si nuestro sitio web está creado usando un sistema de Server Side Scripting (como lo son PHP, ASP, JSP, etc) entonces ya existe la posibilidad de que en nuestros scripts aparezcan potenciales fallos de seguridad. Sobre todo si en uno o más lugares del sitio hay formularios que permitan al usuario enviarnos datos (un formulario de contacto, o un formulario de suscripción a un boletín, por ejemplo).
Si además de usar un lenguaje como PHP o ASP, nuestro sitio usa bases de datos (como MySQL, Oracle, SQL-Server, etc) entonces las posibilidades de ataques se multiplican por diez.
Y si además de usar PHP (o ASP) y bases de datos, utilizamos scripts y programas estándar dentro de nuestro sitio (como ser scripts de administración de contenidos, foros, galerías de fotos, programas de intercambios de enlaces, etc) las posibilidades de resultar vulnerables y ser atacados por intrusos son mucho mayores. Lo mismo ocurre en caso de que usemos scripts o programas CGI.
Aquí van los consejos, en orden de importancia decreciente:
1) Mantener los scripts y programas web actualizados y cambiarlos o parcharlos inmediatamente cuando se descubra un bug o un problema de inseguridad en los mismos
Me refiero a programas como foros, galerías de fotos, webmails, intercambios de enlaces, scripts de suscripción a boletín electrónico, sistemas de votación y encuestas, programas de sindicación RSS, manejadores de contenidos (tipo phpNuke), etc.
Sólo con cumplir este punto (actualizar los scripts y/o programas inmediatamente se conozca una vulnerabilidad) estaremos resolviendo más de un 80% de los riesgos de seguridad.
Ahora vale la pregunta: ¿y cómo hago para informarme inmediatamente cuando se descubre una vulnerabilidad en los scripts que tengo instalados?
Hay varias formas de informarse:
a) el método "paranoico"
Muchos administradores de sistemas visitan diariamente sitios especializados que publican reportes de vulnerabilidades. Algunos de ellos son: securityfocus.com, secunia.com, us-cert.com. El problema de este método es que requiere de una gran dosis de disciplina y constancia: hay que consultar las listas de vulnerabilidades todos los días, revisando una por una a ver si hallamos alguna que afecte a nuestros sistemas. Personalmente tuve que hacerlo durante varios años, y confieso que es aburridor y tedioso.
b) el método automatizado
Consiste en crear una cuenta en Alertahacker.com (o HackerWarnings.com), ingresar al panel de control del servicio y configurar en nuestra cuenta cuáles son los productos que queremos monitorizar: si en algún momento se reporta alguna vulnerabilidad en alguno de nuestros scripts y programas, el sistema nos hará llegar un e-mail inmediatamente alertándonos y adjuntando la dirección de la página web donde se describe el problema descubierto.
Estos servicios son gratuitos y de libre acceso, y no compiten con los sitios que se dedican a registrar y documentar reportes de vulnerabilidades, tal cual lo hacen SecurityFocus (también conocido como BugTraq) o Secunia. AlertaHacker.com se limita a rastrear en la web y hallar reportes de seguridad recientes que se ajusten a las preferencias que le hemos configurado, entonces sólo nos enviará el aviso conteniendo las referencias al sitio del autor original del reporte. Y ésto nos resuelve el problema de estar informados de los fallos de seguridad en nuestro software sin tener que invertir ni un minuto en leer largas listas de reportes de seguridad referentes a programas que ni usamos ni nos interesan.
Una vez enterados de un problema de seguridad en alguno de los softwares que tengamos instalados, el próximo paso será visitar el sitio web original del software en cuestión. Allí buscaremos cuál es la nueva versión del programa. En otros casos hallaremos un "parche" o "actualización" que solucione el problema. Estos parches suelen estar acompañados de instrucciones detalladas que explican cómo instalarlos. También existe la posibilidad de que los autores del programa se estén enterando de la existencia de la vulnerabilidad al mismo tiempo que nosotros… entonces deberemos aguardar a que creen el parche o la actualización, y lo publiquen en su web. En estos casos también es recomendable usar algún buscador para encontrar si en algún otro sitio web o foro alguien describe un método para "parchar" el problema de seguridad por nuestra cuenta (siempre y cuando no resulte muy difícil).
2) Usar un esquema seguro de nombres de usuario y passwords. Origen del 11% de los ataques exitosos contra sitios web
¿Qué es un esquema seguro? Voy a explicarlo mostrando por oposición qué es un "esquema inseguro": mi nombre es Eduardo… si en mi webmail, en mi FTP, y en otros programas web uso el nombre de usuario "eduardo" y el password "eduardo1234", entonces estaré usando un esquema inseguro. Cualquiera que se proponga entrar en algún área privada de mis sitios web, y se tome el trabajo de probar algunas decenas de combinaciones predecibles, pronto dará con los datos, y tendrá control total de mi sitio web. Y si encima cometí el error de usar los mismos datos en mis otros sitios web… entonces puedo considerarme liquidado.
Este tipo de ataques se llaman "ataques por fuerza bruta" y en muchos casos no requieren que el atacante use muchas combinaciones: es sorprendente cómo la mayoría de los usuarios -con el pretexto de no olvidarlas- utilizan contraseñas completamente predecibles, ya se trate de un nombre (de la persona o de la web), un año, una secuencia como "1234" ó "qwert", "asdf", un número de IP, etc.
Muchos artículos escritos por expertos recomiendan usar nombres difíciles, donde se combinen letras mayúsculas, minúsculas, signos de puntuación y números. Por ejemplo: "R47n!Y2a5Mm". No voy a discutir que esto es un password seguro… pero también es horrible para escribirlo cada vez que voy a usar el FTP. Además es difícil, o imposible de memorizar. Y si además en cada sitio web y en cada programa tengo que poner uno diferente… sin duda estaré complicando mi trabajo.
En la práctica resultan buenos passwords aquellos conformados por breves frases como "quebuenaestalavecina" o "mevoyajugaralcounter". Estos no contienen cifras, ni mayúsculas, ni signos de puntuación (por lo que no cumplen con las recomendaciones de mis colegas), y sin embargo son muy difíciles de crackear, aún usando programas automatizados (fundamentalmente debido a su longitud). Y tienen la enorme ventaja de que son fáciles de recordar y de escribir.
Y no olvidemos usar un password diferente en cada uno de los programas, en cada uno de los sitios web. Si vamos a escribir los passwords para no olvidarlos, nunca debe hacerse en un archivo en la PC. Si alguien pudiera penetrar en nuestra PC, se encontraría "de obsequio" con una hermosa lista de direcciones y passwords para divertirse en grande! En este caso es mejor anotar esta información en una tarjeta, y llevarla en la billetera. Al anotar los passwords no es conveniente aclarar completamente a qué corresponden: si alguien encontrase nuestra tarjeta de passwords tendría sólo eso: una tarjeta con passwords (no sabrá de qué cosa o de qué lugar son).
3) Borrar los scripts de instalación de los productos
Cuando instalamos un script, por ejemplo basado en PHP/MySQL, es habitual que durante el proceso de instalación debamos invocar un script que cree las tablas y las estructuras necesarias en las bases de datos. Este script puede llamarse install.php, ó /admin/configure.php, etc. Cada producto tiene su propio procedimiento de instalación, los archivos de creación inicial de tablas tendrán ubicaciones distintas, con nombres distintos.
Una vez que un atacante identificó que en nuestra web estamos usando un producto específico, entonces estará en condiciones de ir al sitio web del producto, leer los manuales de instalación, y luego volver a nuestro sitio y probar con (por ejemplo):
www.sitio-victima.com/admin/install/installdb.php
Recordemos que la misión de este script es crear las tablas de la base de datos, y si en este momento nuestra base de datos contiene información, entonces muy probablemente se esté borrando absolutamente todo el contenido actual (aunque este comportamiento puede variar de producto en producto).
Los manuales de instalación de los scripts normalmente indican cuáles son los ficheros que conviene borrar luego de completada la instalación, luego que el sistema queda funcionando. El problema es que luego de quedar funcionando, muchos webmasters simplemente ponen punto final a la instalación, y dejan funcionando el sitio web sin haber borrado nunca estos scripts que ahora no sólo son innecesarios sino que además resultan peligrosos. Una buena medida de seguridad sería revisar sitio por sitio a ver si hemos olvidado borrar alguno de estos scripts de instalación. Piensa que tal vez en este mismo momento alguno de tus enemigos esté leyendo este artículo, y sea él quien se tome el trabajo de revisar a ver si olvidaste borrar alguna de estas "bombas de tiempo".
Y aquí terminan mis recomendaciones. Por ahora son pocas: sólo 3 (para que nadie tenga excusa para no ponerlas en práctica). Sin embargo al resolver estos 3 puntos estaremos cubriéndonos de más del 96% de los potenciales riesgos que afectan un sitio web (siempre haciendo referencia a los aspectos que dependen exclusivamente del webmaster, y no del administrador del servidor).
De modo que es momento de poner manos a la obra, y empezar a buscar y solucionar los detalles que pueden representar vulnerabilidades en nuestros sitios web.
Y tener presente que la seguridad es un proceso permanente: un sitio web que es seguro hoy, puede no serlo la semana próxima si se descubre un fallo en alguno de los scripts o programas que tengamos instalados.
Estrategias de seguridad para webmasters (II)
En el artículo anterior se explicaron dos métodos para mantenernos informados acerca de nuevas vulnerabilidades (o exploits) que se descubran en los scripts y programas que usamos en nustros sitios web. Pero -tal vez por no profundizar lo suficiente- en muchos lectores se generó una sobreexpectativa, incluso llegando alguien a pensar que el servicio alertahacker.com analizaría sus sitios web y le enviaría soluciones.
Este artículo explica cómo podemos hacer para descubrir si los scripts que hoy tenemos instalados son vulnerables, sin requerir para ello la instalación de ningún software. Y se recalca el concepto de que la securización de un sitio web se debe llevar a cabo en dos etapas: (1) implementación inicial de seguridad y (2) mantenimiento.
Partir de una base segura (implementación inicial de la seguridad en nuestra web)
Lo primero que se debe hacer en un sitio web es seguir las recomendaciones de los puntos 2 y 3 del artículo anterior: cambiar todas las contraseñas inseguras, y borrar todos los scripts de instalación. Acto seguido, debemos verificar que las versiones de los scripts instalados no presenten vulnerabilidades que los hagan inseguros. Esta verificación no la haremos consultando las listas de nuevos reportes de seguridad, ni esperando los reportes de nuevas vulnerabilidades de alertahacker.com.
Supongamos que tenemos instalado un script de galerías de fotos, (el programa X versión 1.2) una versión que hemos instalado en el año 2003… Si buscamos las nuevas vulnerabilidades que permitan realizar ataques sobre este script, posiblemente no se reporte ninguna (sencillamente porque no existan nuevas vulnerabilidades). Pero sí es posible que existan antiguas vulnerabilidades.
Desde el año 2003 –cuando instalamos el script- hasta la fecha tal vez hayan sido descubiertos y reportados varios exploits que afecten este producto. Estos reportes ya estarán archivados. Ahora son historia, y no los hallaremos en los listados de vulnerabilidades recientemente descubiertas, ni en los resultados que alertahacker.com nos enviará por e-mail.
Confirmando si existen vulnerabilidades en un script instalado
El camino a evitar: complejos análisis y escaneos por nuestra cuenta
Cuando a un administrador de sistemas se le plantea el problema de verificar si un script o una instalación presenta agujeros de seguridad, lo primero que hace es echar mano a los programas de escaneo de vulnerabilidades (como Nessus, Retina, GFI-LanGuard, etc). Pero si bien el uso de estos programas a primera vista parece sencillo, en la práctica requieren de muchos "ajustes finos" si realmente queremos profundizar en el análisis de scripts específicos.
El estudio de este tipo de programas está fuera del alcance de este artículo. Es más, no recomiendo a ningún webmaster el uso de estos programas Si el usuario no es un verdadero experto, lo que obtendrá será un doble perjuicio: por un lado una gran lista de falsos positivos (el escaner dice haber encontrado una vulnerabilidad cuando en la práctica ésta no existe), y por otro lado una serie de vulnerabilidades que existen y no serán detectadas por el escáner (al menos no con su configuración por defecto).
Después de haber realizado un escaneo con alguno de estos productos, el webmaster quedará mal orientado: verá fantasmas donde no los hay, a la vez que ignorará problemas de seguridad reales que no fueron detectados.
La forma directa de buscar vulnerabilidades
Resulta más fácil de lo que se esperaba: simplemente recurriendo al ya conocido Google buscamos algo así como "vulnerabilidad programa X 1.2" ó "actualización X 1.2" o en inglés "expliot X 1.2" o "security X 1.2". Ustedes ya saben… a estas alturas no voy a tratar de enseñar cómo se busca en Google.
Si en algún sitio existe algún reporte archivado que haga referencia a vulnerabilidades o actualizaciones para el programa X versión 1.2, sin duda Google lo encontrará y traerá el link a nuestra pantalla. Alternativamente podemos entrar al sitio web oficial del programador del script y leer la lista de actualizaciones y nuevas versiones del programa.
Si se confirma que el script en cuestión tiene agujeros de seguridad, entonces simplemente lo actualizamos a su última versión estable. Si no descubrimos ninguna vulnerabilidad, ya que estamos trabajando en esto, igual sería bueno actualizar el programa a su última versión estable. 😉
Supongamos que ya tenemos actualizadas y seguras todas las instalaciones de scripts en nuestros sitios web. Como se decía en el artículo anterior: "un sitio web que es seguro hoy, puede no serlo la semana próxima si se descubre un fallo en alguno de los scripts o programas que tengamos instalados." Aquí es donde entraremos en la etapa de mantenimiento, y aquí es donde alertahacker.com nos prestará un gran servicio: al informarnos de las nuevas vulnerabilidades que sean reportadas de ahora en adelante.
Es importante entender que la tarea de securizar un sitio web se debe encarar dividiendo el trabajo en dos claras etapas: a) implementación inicial de la seguridad, y b) mantenimiento de la seguridad. Cualquiera de estas dos etapas realizada por sí sola no nos dará resultados. Si queremos realizar un mantenimiento de seguridad en un sitio web donde no se implementó inicialmente la seguridad, estaremos haciendo un trabajo sin sentido y sin resultados: recibiremos las alertas de seguridad relativas a las nuevas vulnerabilidades, pero estamos peligrando a través de las vulnerabilidades antiguas que no hemos corregido inicialmente.
Ing. Eduardo González González (*)
(*) Consultor en Sistemas de Seguridad