- 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