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í:
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:
Un ejemplo lo podemos tener ejecutando el WebFuzzer, con licencia GPL, escrito en C:
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.
