Debido a los avances en nuestro medio tecnológico, nos encontramos con situaciones que nos amargan la existencia, como por ejemplo: cuando nuestras webs se caen, ingreso de virus a nuestro PC, spam en nuestros correos, etc.

El término se empezó a utilizar en el año 2000 por Luis von Ahn, Manuel Blum y Nicholas J. Hopper de la Carnegie Mellon University, y John Langford de IBM.

El sistema Captcha tiene las siguientes características por definición:

Son completamente automatizados, es decir, no es necesario ningún tipo de mantenimiento ni de intervención humana para su realización. Esto supone grandes beneficios en cuanto a fiabilidad y coste.

El algoritmo utilizado es público. De esta forma, la ruptura de un captcha pasa a ser un problema de inteligencia artificial y no la ruptura de un algoritmo secreto.

Pues habiendo visto un poco lo que es captcha “Completely Automated Public T uring test to tell Computers and Humans Apart (Prueba de Turing pública y automática para diferenciar a máquinas y humanos).

En este escenario, podríamos encontrarnos con dos situaciones bien diferentes:

• Tener un sitio montado y tener que protegerlo.
• Programar un sitio desde cero.

Escape de las entradas. Para muchos la manera ideal de proteger un site. Como ya hemos visto en alguno de los casos, no nos es útil. Los más habituales son el uso de:

• addslashes() / stripslashes()
• htmlentities($string, ENT_QUOTES)
• htmlspecialchars()
• mysql_real_string()

Teniendo activadas las magic_quotes_gpc en nuestro php.ini, que nos pondrá por defecto un slash en todos los strings (evitando los tediosos "addslashes()"). En todo caso, el uso de dichos elementos nos podrá salvar de muchos de los ataques.

Evitar, salvo en casos necesarios, que los formularios POST se llamen desde otro dominio que no sea el del propio servidor. En este caso, nos evitaremos que un atacante avezado utilice un script a tal efecto para ir bloqueando nuestro servidor y llenándolo de datos inútiles.

Vamos a ver, ¿qué clase de configuración sería la óptima para que un sistema PHP fuera más seguro contra todo tipo de ataques?

Estas directivas serían:

Openbase_dir
Esta directiva bien configurada evitará los ataques "trasversal directories", debido a que limita ejecución de ficheros al entorno que escojamos.

Allow_furl_open off
Es importante que esta directiva esté en OFF para evitar "Remote File Inclusion", ya que la inhabilitación de esta directiva no permitirá a la aplicación hacer include remotos.

Register_globals off
Como ya hemos explicado, quizá la más maléfica (y obsoleta) forma de que nuestros atacantes desplieguen todo su potencial es mediante esta directiva activada. Es decir, cualquier parámetro que nos venga por POST o GET puede ser una variable potencialmente peligrosa en nuestro aplicativo. Así, cualquier parámetro externo se tratará de forma cuidada con $_GET['param'], $_POST['param'], $_FILES['param'] para establecer qué tipo de variables son externas y cuáles no.

No se recomienda, a no ser que se tenga muy claro qué se está haciendo, el uso de $_REQUEST, pues ahí puede entrar 'cualquier cosa' que nos venga externamente, y fácilmente podrían introducirnos valores no esperados.

Safe_mode on
Esta directiva activada evitará la ejecución de algunos comandos potencialmente dañinos en nuestro sistema, además del chequeo de ciertas funciones que puedan considerarse delicadas. Una lista de dichas funciones puede encontrarse aquí:

php.net/manual/en/features.safe-mode.functions.php

Especial atención merecen también las directivas “safe_mode*” que componen la familia.

• safe mode:
• safe_mode_gid
• safe_mode_include_dir
• safe_mode_exec_dir
• safe_mode_allowed_env_vars
• safe_mode_protected_env_vars

Por último, unas funciones que, según la casuística de nuestro aplicativo pudiera evitarnos algún susto por la ejecución de comandos sensibles que no queremos (y no debemos) utilizar:

• disable_functions <lista de funciones>
• disable_classes <lista de clases>

Escaneo de puertos Una manera de evitar ataques a todo sistema operativo, ya sea mediante web o mediante cualquier otro tipo de vulnerabilidad, sería mediante la ejecución de código remoto o inyección de código no deseado en servicios que puedan tener relación con nuestro sistema.

Para ello se recomienda ejecutar un escaneo de puertos de nuestra máquina (no únicamente puerto 80-http o 443-SSL) para averiguar las posibles vulnerabilidades o exploits que puedan afectar a nuestro sistema y servidor web:

Los más conocidos son nmap y nessus. El funcionamiento de nmap puede llegar a ser sencillo, aunque tiene un despliegue de opciones que, a buen seguro, mucha gente encontrará interesante.

Una ejecución de este programa puede dar lugar a un resultado como este:

Starting Nmap 4.53 ( http://insecure.org ) at
20080603
12:05 CEST
Interesting ports on 192.168.1.1:
Not shown: 1711 closed ports
PORT STATE SERVICE
21/tcp open ftp
23/tcp open telnet
80/tcp open http
MAC Address: 00:02:CF:81:6F:89 (ZyGate
Communications)

Nessus, en cambio, nos ofrecerá una herramienta cliente/servidor que utilizará una base de datos con las vulnerabilidades que estadísticamente han podido ocasionar “desastres” y nos avisa mediante este escaneo.

La interfaz, además, es bastante más amigable y nos mostrará unas estadísticas de los procesos ejecutados.

Escaneo de vulnerabilidades web

Más en consonancia con el objetivo de este artículo, están los escaneos de vulnerabilidades propiamente web. Estos escaneos se pueden basar en varias premisas, empleando sistemas de conocimiento, funciones heurísticas e incluso técnicas fuzz, que veremos más adelante. Una buena combinación de estos elementos puede darnos muchas pistas a la hora de proteger nuestro site y llegar donde nosotros no alcanzamos. Empecemos por los escaneadores automáticos más empleados y populares.

Acunetix

Acunetix, que goza de una versión Free Edition (sólo para HTML Injection), pero con una gran variante de sistemas de inyección, una base de datos amplia y una interfaz muy amigable. Los procesos por los que puede “atacarse” pueden ser varios y los perfiles de ataque – si se tiene la versión de pago – de los más variopintos, muchos de ellos ya los hemos visto aquí.

SSS (Shadow Security Scanner)

Similar al anterior en cuanto a sistema web, quizá no tan completo, pero que ofrece también el sondeo de otros protocolos como FTP, NetBios, módulos de Apache del que se tengan constancia que hay vulnerabilidades.

Técnicas Fuzz

Se llama fuzzing a las diferentes técnicas de testeo de aplicativos que generan datos secuenciales y aleatorios para obtener así las vulnerabilidades de la victima. Este sistema puede ser muy potente, pues combina la aleatoriedad en los ataques con ataques basados en formatos heurísticos. Una lista de estos potentes escaneadores de vulnerabilidades pueden encontrarse en:

www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html

Un ejemplo lo podemos tener ejecutando el WebFuzzer, con licencia GPL, escrito en C:

/gunzip.altervista.org/g.php?f=projects#webfuzzer

PHP IDS

PHP-IDS es un sistema basado en PHP que actúa como IDS (Intrusion Detect System) y que se aplica a todos nuestros archivos buscando algún tipo de inyección o vulnerabilidad. Puede detectar desde XSS, SQL Injection, RFI y ataques LDAP Injection y tiene incluso hasta módulos especializados para distintos tipos de CMS.

Módulos Apache

De entre ellos, existen muchos que nos pueden ayudar a nuestro cometido, aunque nos centraremos en los siguientes:

Mod_rewrite
Famoso sobre todo para el uso de URL-Friendly, pues reescribe la entrada transformándola en otras “Human readibility”. Personalmente recomiendo el uso de mod_security, debido a que mod_rewrite tiene lógicas limitaciones al no ser un módulo diseñado a tal efecto.

Conclusión

No es un caso trivial tener que proteger un site web, tanto si ya está hecho como si lo tenemos que desarrollar de nuevo. La única forma de obstaculizar el ejercicio de estos atacantes será conocer cuáles son sus técnicas, mantenerse actualizado regularmente de las vulnerabilidades de nuestro entorno (Sistema Operativo, Lenguaje, base de datos y módulos y librerías asociados), en caso de ser un programa conocido (como un WordPress, Joomla!, PostNuke) mantenerse alerta a los bugs que, altruistamente, algunos atacantes publican en webs.

Además, con un sistema IDS que nos pueda ir comunicando qué pasa con nuestros logs, la evolución de estos mismos y la constante evaluación de las vulnerabilidades de nuestro sistema, junto con un escaneo automático, técnicas fuzz y una programación sólida, y algún módulo destinado a la seguridad harán de nuestro servidor web una fortaleza (casi) inexpugnable.