IONCUBE

Bueno, luego de llevar 3 días con el Forbidden en la frente, solventé la cuestión con el htaccess.

Luego de hacerme un master sobre .htaccess, pero como soy nuevo en el mundo del scripting, resulta que los progrmas vienen todos encriptados para que no veamos su código y así poder copiarlo, mejorarlo, etc. Cosas del mundo propietario.-

Sin más preámbulo, pasemos al aspecto ténico:

Ioncube es una empresa que ente otros, ofrece soluciones para codificar y decodificar scripts PHP. Sin embargo, al igual que ocurre con Zend Optimizer u otros, necesita de un decodificador instalado en el lado del server para poder decodificar los scripts que serán ejecutados por PHP. Vamos a ver como instalar Ioncube Loaders en nuestro servidor CentOS, Ubuntu, Red Hat, Debian / (para cualquier distro Linux):

Vamos a la web http://www.ioncube.com/loaders.php

Descargamos el installer para Linux correspondiente a nuestra arquitectura, por ej:

Descomprimimos:

Nos fijamos que versión de PHP usamos, en mi caso 5.2:

Y copiamos el archivo correspodiente:

Luego agregamos el módulo como primera extensión zend, incluso antes que zend optimizer, en caso de estar instalado:

Quedaría así:

Reiniciamos el servidor web, y debería estar listo, tipeamos php -v y tendríamos que ver algo como esto:

 

Buscando vulnerabilidades de inyección SQL

Tras unas horas de chateo con mi amiga hacker favorita, me puso en la última de las herramientas para buscar vulnerabilidades:

Aquí les dejo el enlace:

http://itsecteam.com/en/projects/project1.htm

Se llama Havij que, ahora mismo, va por su versión 1.14. Este programa resulta de gran utilidad para comprobar el estado de seguridad de nuestras webs y aplicaciones en la red.

Anda date una vuelta y adquiere esta magnífica herramienta. Yo la he estado probando y la verdad que va bastante bien.

«Me comprendes Méndez..??»

 

 

Seguridad básica para WordPress por medio htaccess

Además de la optimización, el fichero .htaccess nos proporciona una seguridad complementaria a todos los plugins que WordPress y su comunidad nos pueda ofrecer. Existen unas premisas básicas de seguridad para empezar.  Las dos primeras son de relleno pero que TODO el mundo debería saber:

  1. Conocer nuestro hosting a la perfección y saber quién está detrás de éste (shared,gratuito,ftp,sftp,ssl, cpanel,permisos,…). Parece una tontería, pero a veces muchos se olvidan de algo tan primordial como no informarse del sitio donde «va a comenzar a vivir su idea o su proyecto». Puede que en otro post hablé sobre los hosting, los SEO hosting, los hosting «baneados» e incluso de la temática de seguridad en dominios, haciendo hincapié en los ccTLD, sobretodo los .es, que gozan de desprotección a nivel legal.
  2. Conocer nuestro lugar de trabajo, o sea, nuestro ordenador. Debemos mantenerlo actualizado y limpio, tanto de registro como de todo tipo de malware residente (para los más puristas, lo siento, incluiré dentro de este término troyanos,keyloggers,rootkits,virus de cualquier índole,macros o scripts perniciosos,etc…). Haremos un post sobre ello, y el arsenal de herramientas gratuitas con las que contamos.

Tras esto, ¿qué debemos tener en cuenta antes o una vez instalado nuestro wordpress?

  • Protegernos mediante el .htaccess y a su vez protegerlo de agresiones exteriores.
  • Proteger los core o los ficheros núcleos como wp-config.php
  • Proteger nuestro blog de curiosos que intentan indexarlo y ver la estructura de los archivos en el servidor.
  • Proteger el blog de todo tipo de SPAM y del hotlinking que agota ancho de banda y enlentece nuestro WP.
  • Evitar en la medida de lo posible ataques mediante inyección SQL u otro tipo de vulnerabilidad que posea tanto servidor como blog.

Pasos a seguir:

  • Si existe .htaccess, haz una copia de seguridad de éste antes de introducir cualquier modificación, ya que en caso de «cagada» siempre puedes volverlo a subir por ftp o por un administrador de archivos.
  • Para los más novatos, recordarles que puedes generar el archivo a partir de un archivo de texto .txt y después renombrarlo a .htaccess. Recuerda: sin extensión alguna, tal cuál.
  • Cualquier error en la síntaxis del archivo puede ocasionar un mal funcionamiento del servidor donde alojas el blog.
  • Nunca dejes que el público pueda escribir en el .htaccess. Recuerda dejarlo siempre en 644, salvo que se indique otra cosa por motivos de compatibilidad.
  • Activa la función mod_rewrite ya que a veces está por defecto en off en muchas configuraciones de servidores:

# Activa la funcion reescritura
RewriteEngine on

  • Proteger .htaccess del exterior. La gente suele ponerlo en el directorio root, pero en algunas ocasiones puedes colocarse en la carpeta que deseamos proteger. El código es el siguiente:

# Proteger el htaccess
<files .htaccess>
order allow,deny
deny from all
</files>

  • Protección de wp-config.php. Editamos el .htaccess en el directorio donde está alojado el archivo. El código es el siguiente:

# Proteger wpconfig.php
<files wp-config.php>
order allow,deny
deny from all
</files>

  • Ahora vamos a deshabilitar que nuestra estructura de archivos y carpetas sea visible desde cualquier navegador. Esto permite en algunas ocasiones acceder a archivos o documentos que no queremos, además de revelar información sobre nuestro hosting y el tipo de servidor que utiliza para explotar vulnerabilidades. Un código simple:

# Desahilitar navegacion
Options All -Indexes

  • Se hace difícil protegernos sobre el spam en nuestros comentarios, puesto que si nos pasamos filtrando no dejaremos escribir a casi nadie y nuestro tráfico emprezará a decrecer como una cosa mala. Actualmente, existen programas o scripts que chequean la web en busca de blogs objetivos. Algunos son spammer generales o bots y otros son tipos con visión comercial que actúan sólo en blogs dónde existen determinadas keyword o temáticas. El uso de «armas» como Xrummer, SeNuke, HummingBird, Demon o Blog Commenters Automáticos permiten saltarse algunas normas y llegar disimuladamente hasta nuestros blogs para promocionarse, obtener backlinks de blogs con PR y ofrecernos enlaces cortos que redireccionan a anuncios CPA o aplicaciones facebook. Son consideradas técnicas de blackhat y los buscadores suelen rechazar y banear toda web o dominio que origine alteraciones y variaciones en las SERPs. Ahora bien, además del los plugins antispam para wordpress, podemos adornar nuestro htaccess con el siguiente código:

# Proteger WP de spammers
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*YOURDOMAIN.com.* [OR] RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L] </IfModule>

  • Cuando el ancho de banda se te dispara de forma alarmante y tus visitas siguen igual, todo nos hace sospechar en que alguien te está robando las imágenes u otro archivo media que tengas en el servidor. Hace unos años era primordial evitar todo esto. En la actualidad, hay diferentes maneras de pensar en acciones antes adoptar una decisión final. Por ejemplo, puede ser positivo si Google Images o  te indexa tus fotos y los visitantes acaban en tu sitio. También muchos bots automáticos hacen una repasada general para indexarte y si tienes titulos y alt en todas tus fotos te irá genial para temas SEO. Por otro lado, el ancho de banda ya no se paga tan caro como antes, es más, muchas compañías de alojamiento te lo ofrecen ilimitado por cuatro duros. La trampa está en que tu imagen sea muy «famosa» y miles de visitantes la vean indexada y realicen miles de consultas en tu web. Entonces, dependiendo de tu hosting, puedes reducir la memoria del procesador y tirar para abajo la web e incluso en el caso de multidominio en shared, todos los demás proyectos. El siguiente código te ayudará a tu lucha diaria contra el hotlinking (aunque también existen plugin en WP que hacen lo mismo). Para que la operación tenga éxito, debes subir una imagen jpg (p.ej con el lema: No robes ancho de banda) a cualquier host de imágenes gratuito como ImageShack, Flickr o Picasa. Anotas el enlace directo y lo sustituyes donde está OTRODOMINIO.com.

# Proteccion WP Hotlinking
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?YOURDOMAIN\.com/ [NC] RewriteRule .(jpg|jpeg|png|gif)$ http://ANOTHERDOMAIN.com/nohotlinking.jpg [NC,R,L] </IfModule>

  • Controla las descargas que ofreces en el blog y fuérzalas a que no puedan agregarse a gestores de descargas. Como véis, esto es muy opcional ya que las nuevas versiones de WP ya tienen bajo control esto, pero si quieres intentarlo:

<FilesMatch "\.(mov|mp3|pdf)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>

  • Los siguientes códigos no son protectores pero si que te ayudarán a mejorar el rendimiento del server, ahorrando transferencia y cargando más rápido la página, puesto que ahora Google lo tiene en cuenta en su algoritmo de valoración. Si el hosting tienen la función php enabled, puedes usar la compresión al vuelo. O sea, tú le das al usuario el formato comprimido (ahorrando tranferencia) y éste, si su navegador soporta la descompresión al vuelo (90% lo hacen),lo recibe rápidamente. Ganáis los dos. Ahí va el código:

# Ahorro de tranferencia para servidores PHP enabled
<ifmodule mod_php4.c>
php_value zlib.output_compression 16386
</ifmodule>

  • Cacheando que es gerundio. No es lo mismo tener que realizar todo el rato la consulta (gastaremos ancho y consumimos CPU), que habilitar la caché para ciertas funciones y durante un tiempo determinado para ahorrar y servir las páginas a buena velocidad. A veces, a pesar de tener un servidor dedicado el consumo se hace excesivo para blogs con un volúmen muy alto de visitas llegando a asfixiar al server y al webmaster. En algunas empresas, se habla del concepto de balancear la carga, donde se reparten las consultas a base de datos, los archivos multimedia, etc… en diferentes servidores con el objetivo de descentralizar todos los procesos y producir posteriormente una potente sinergia que origina una web rápida y robusta. De todas formas, para los pequeños wordpresseros se sigue usando la caché y los plugins destinados a tal fin. En otro post veremos que el concepto está empezando a cambiar con la forma de trabajo a los cloudfront y algunos servicios como S3 de Amazon. El código es bastante extenso según cuál sea su uso:

# cachear imagenes y contenido flash durante un mes
<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

# cachear texto css y javascript durante una semana
<FilesMatch ".(js|css|pdf|txt)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>

# cachear html y htm durante un dia
<FilesMatch ".(html|htm)$">
Header set Cache-Control "max-age=43200"
</FilesMatch>

# deshabilitar la cache para scripts y archivos dinamicos
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>

# metodo alternativo para cachear archivos
ExpiresActive On
ExpiresDefault A604800 # 1 week
ExpiresByType image/x-icon A2419200 # 1 month
ExpiresByType application/x-javascript A2419200 # 1 month
ExpiresByType text/css A2419200 # 1 month
ExpiresByType text/html A300 # 5 minutes
# disable caching for scripts and other dynamic files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
ExpiresActive Off
</FilesMatch>

  • Los tiempos los puedes fijar siguiendo este patrón: 300 son 5 minutos y 3600 es 1 hora. 604800 será un mes, entonces. Y así, hazte una regla de tres.
  • Prohibiciones. Representan una función específica de seguridad para algo en concreto. Estos son los códigos derivados de lo que hemos visto antes:

# protege un archivo en concreto
<files secretfile.jpg>
order allow,deny
deny from all
</files>

  • Si lo que quieres es proteger unas determinadas extensiones que también se alojan en tu carpeta root o en el blog, aquí tienes el código. Recuerda que puedes sustituirlos por la extensión que tú eligas:

<FilesMatch "\.(htaccess|htpasswd|ini|phps|fla|psd|log|sh)$">
Order Allow,Deny
Deny from all
</FilesMatch>

  • Modos de seguridad avanzada para .htaccess. Existen muchos más, pero sólo voy a nombrar los que me han parecido más útiles para trabajar con wordpress. El primer código sirve para cambiar el index.php por otra página que queramos:

# alternativa al index por defecto
DirectoryIndex otrapagina.html

  • Permitir el acceso sólo a una determinada IP. Esto nos va a ir bien si queremos que nadie acceda al wp-admin, por ejemplo. Asignamos nuestra IP y se acabó. En el ejemplo, vemos que sólo la IP 80.78.2.35 es la que tendrá acceso al wp-admin. Esto es mucho más efectivo que cualquier plugin pero, desgraciadamente, una gran mayoría de gente tiene ip dinámica. Una solución sería darse de alta en algún servicio gratuito de IP estática y el problema quedaría solventado.

# deniega acceso a todos excepto a la ip que indica
<Limit GET POST PUT>
order deny,allow
deny from all
allow from 80.78.2.35
allow from .*domain\.com.*
</Limit>

  • Si estáis en una empresa liados con un proyecto en WP, o bien, dispones de una pequeña red doméstica, puedes limitar tu blog sólo a la LAN local:

# limitar el acceso a local area network
<Limit GET POST PUT>
order deny,allow
deny from all
allow from 192.168.0.0/33
</Limit>

  • Si estás mirando las estadísticas y recibes la visita periódica de un dominio sospechoso que no te gusta ni un pelo, puedes quitártelo del medio con el siguiente código (sustituyendo los nombres que ves por los que se reflejan en las estadísticas o los que consideres):

# bloqueo de visitantes a traves del dominio
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} dominiotocapelotas\.com [NC,OR]
RewriteCond %{HTTP_REFERER} dominiosospechoso\.com [NC,OR]
RewriteRule .* - [F]
</ifModule>

Rango de IP de operadores en España

Por si queremos permitir solo tráfico en España con htpaccess:

htaccess básico

Un poco de seguridad con htaccess

Mientras ecucho los Redonditos…Atención, abrir en una nueva ventana.

Quizás sean pocos los lectores a los que no le suene la potencialidad de htaccess, sin embargo a menudo solemos infrautilizar todo el potencial que este pequeño archivo de configuración puede encerrar.

Htaccess es un contenedor de directivas y reglas que guardado a nivel de directorio de nuestro proyectos web complementan el archivo de configuración de Apache.

Uno de los planteamientos mas divertidos de .htaccess es su uso como herramienta de seguridad, o más bien de ofuscación de nuestros archivos y directorios, de manera que ayude a mantener a “mentes curiosas” lejos de los archivos y directorios sensibles de nuestros proyectos.

A menudo cuando se trabaja en la dura realidad de la empresa, donde la productividad pesa más que la elegancia, nuestros proyectos web son lanzados no todo lo maduros que desearíamos, por lo que un buen .htaccess puede ahorarnos algun bochorno delante de nuestros clientes.

A continuación voy a describir una serie, de técnicas, que pueden ayudarnos a relajar un poco la seguridad de nuestras aplicaciones o guardarnos un poco las espaldas, cuanto usamos código de otras personas.

No voy a entrar demasiado en detalle de las explicaciones de directivas y expresiones ya que hay suficiente documentación en la Red sobre ello.

Como otros artículos de este site, no pretendo arrojar otro manual mas de htaccess a la Red, sino mas bien aportar algunas ideas que el lector debe ajustar a sus necesidades y estrategias.

Activar .htaccess

Para que htaccess sea funcional hay que especificar la directiva en nuestro host virtual:

También puede ser que necesites un:

Activar mod_rewrite

La mayoría de reglas usan mod_rewrite, ya que se basan en el filtrado del URL y no en tareas de acceso propiamente a archivos y direcctorios,  por tanto debemos disponer de el en nuestro servidor.
Si usamos un hosting publico, habrá que comprobar que esta soportado. Si administramos nuestro propio hosting basta con un:

Para familiarizarte en profundidad con mod_rewrite visita su documentación oficial.

Algunas reglas de seguridad para el htaccess interesantes:

Inyecciones SQL

Una de las pesadillas más antiguas de las vulnerabilidades web son las inyecciones sql. Mediante la inyección de fragmentos de código SQL en los valores de nuestras variables:

mipass=’ OR »=’
miuser=’ AND 0 UNION SELECT 1 AND ‘l’=’

A veces se pueden conseguir algunos resultados divertidos. El uso del siguiente conjunto de reglas nos ayudará a filtrar la mayoría de estas situaciones:

Bloqueo de agentes y utilidades de línea de comandos

Algunas herramientas de búsqueda y explotación de vulnerabilidades o los conocidos downloaders poseen agentes particulares y fáciles de detectar como: wget, curl, java, HTTrack, perl, java, etc

Si por ejemplo hacemos en nuestra terminal un:

Obtendremos un “Petición HTTP enviada, esperando respuesta… 403 Forbidden” siempre y cuando tengamos este código en nuestro .htacces:

Inclusión de archivos remotos (RFI) y compañía

Mediante las técnicas de XSS o RFI se incluye en nuestra web un script albergado en otra URL, normalemente una web anfitriona que ya fue atacada previamente, que va a servir para alterar el comportamiento de nuestra aplicación y probablemente servir de puerta de entrada para algún backdoor o shell:

miVariable=http://urlatacante.com/shell.php

Las siguientes reglas nos van ayudar a minimizar este tipo de situaciones o la navegación de directorios desde la url:

Bloqueo de acceso a directorios:

Quizás una de las reglas mas curiosas es simplemente evitar que el usuario pueda acceder directamente al árbol de directorios directamente desde la url:

Gracias a esta sentencia obtendremos un “Forbiden” si hacemos un:

http://www.miweb.com/cache

Bloquear el acceso a determinados archivos

Una técnica un poco mas refinada que la anterior. Se basa en la posibilidad de restringir el acceso directo a ciertos archivos de nuestra web en función de su extensión: php, xml, tpl, etc

Así de esta forma si hacemos un:

http://www.miweb.es/library/index.php
http://www.miweb.es/cache/rss.xml

Vamos obtener un “404 Not Found”. Fíjate que donde antes hacíamos [F] de “forbiden” ahora con [R=404] arrojamos un 404 o cualquier otro error, una técnica interesante para «despistar».

Protección por contraseña de direcctorios

Un clásico de la protección de directorios con .htaccess es la protección mediante contraseña. Esta técnica es interesante para reforzar la autenciación de paneles de control o formularios de autenticación.
Para proteger con contraseña un directorio basta con crear un .htaccess en dicho directorio con el siguiente código

En la directiva AuthUserFile deberemos colocar la ruta de nuestro archivo de passwords. Hay abundante documentación sobre la creación de los passwords de htpasswd. Por ejemplo desde una terminal podemos teclear:

Nos arrojará el contenido de nuesto archivo de passwords:

El archivo .htpasswd puede denominarse con cualquier otro nombre y debe colocarse fuera de cualquier ruta pública, y de ser posible fuera del open_basedir del PHP.

Tienes la documentación sobre la creación de passwords para htpasswd.

Protección de directorios por IP

El tema de la protección con contraseña esta bien, pero es engorroso tener que memorizar dichas contraseñas. Si accedemos siempre a nuestras web desde la misma ubicación, quizás sea interesante una protección por IP o rango de IP.
Para ello podemos usar por ejemplo:

Este ejemplo es válido si tenemos una ip fija. Sin embargo si lo que nos interesa mas que proteger un directorio es ofuscarlo para sacarnos de encima un porcentaje amplio de fisgones, podemos autorizar el acceso para un determinado rango. Podemos ver que IPs publicas se nos asignan comúnmente y abrir nuestro directorio para ese rango, por ejemplo:

De esta forma estamos dando acceso a todo el rango 83.165.xxx.xxx

Esta técnica se puede combinar con la anterior para evitar tener que introducir la contraseña desde ciertas conexiones:

La directiva “Satisfy any” nos indica que tenemos que cumplir una de las dos condiciones, si usásemos “Satisfy All” debemos cumplir las dos condiciones.

Otro uso bastante interesante de las directivas Allow o Deny es poder limitar el acceso de usuarios por país.

En paginas como esta www.ipaddresslocation.org podemos obtener el rango de IPs de un país para permitirlo o denegarlo. Esta técnica sencilla de implementar nos ahorra bastantes curiosos entre nuestros archivos, ya que la mayoría de intrusos provienen del extranjero.

Al final de esta web teneis un htacces para restringir el acceso sólo a visitantes que se conecten desde España.

Manejo de errores

Administrar correctamente los errores generados por nuestra web es una útil técnica de ofuscar la estructura de nuestras web. De los errores que arroja una web se puede aprender mucho, si un directorio existe aunque este prohibido su acceso, si determinado método esta o no habilitado, etc,… Ocultar, ofuscar, confundir, etc personalizando nuestros errores mas frecuentes es una divetida técnica de seguridad.

Por ejemplo con:

Redirigiremos al usuario a la página principal de nuestro dominio sin dar mas explicaciones. Sin embargo esta técnica si la aplicamos en subdirectorios nos puede servir, sin embargo si la usamos en el root de nuestro sitio, acabará redireccionandose a si misma, generando un error en el explorador.

Con esto:

Redirigiremos al visitante a una página, indicando que ha habido un error pero sin decir cual. Es una forma elegante de solucionar la situación.

Si no queremos complicarnos también se puede solucionar así:

Cuando se produce un error que no hemos controlado, también se volcará la firma del explorador: versión, módulos, sistema operativo, etc,… esta información es igualmente útil para conocer posibles vulnerabilidades del mismo. Dicha situación se puede evitar con un simple:

Restringir acceso a determinados archivos

A veces puede ser interesante denegar cualquier acceso a determinados ficheros. Las directivas Files y FilesMach permiten a través de expresiones regulares controlar el acceso a determinados archivos o directorios. Por ejemplo:

Bloquea cualquier acceso a un fichero que termine con la extensión .old

De forma similar:

Bloqueará el acceso a cualquier fichero o directorio que empiece por una barra baja “_”

Exploración de directorios.

Hoy en día la mayoría de hostings ya lo traen correctamente configurado, pero la posibilidad de listar el contenido de nuestros directorios, no suele ser una buena opción salvo que sea intencionada.
La exploración de directorios se puede evitar con un simple index.html o index.php por directorio, pero lo mas elegante es un:

Conclusiones

Estas son algunas propuestas, que combinadas de forma oportuna pueden ayudarnos, quizás no, a blindar nuestra web, sino más bien a borrar las máximas evidencias posibles que puedan dar indicios, a los usuarios más curiosos, de posibles vulnerabilidades en nuestro sitio.

 

Seguridad en Apache con rewrite y .htaccess

Bueno, no hay bien que por mal no venga, investigando como hacer funcionar mi script le he dedicado más tiempo al módulo rewrite.

Para el que no lo sepa como yo hace algún tiempo el  mod_rewrite es un módulo del servidor web Apache que a través de un .htaccess, reescribir urls.

Lo cuál nos da un número de posibilidades interesantes, por ejemplo direccionar las páginas de error a paginas personalizadas, además con esto, se ganan puntos en Google, para mejorar el posicionamiento de nuestra página, también permite ‘ocultar’ los parámetros que se envían de una página a otra, dificultando una posible inyección de SQL. Por ejemplo, una llamada que antes era:

http://adrianramirez.es/noticia.php?id=30

pasa a ser, por ejemplo:

http://adrianreamirez.es/listado_de_noticias/30

Todo esto conseguido gracias a un pequeño fichero .htaccess similar a este:

<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine on
RewriteRule ^listado_de_noticias/([0-9]+) noticia.php?id=$1 [L,NC]
</IfModule>

Como vemos, por un lado oculta la url original y por otro restringe mediante el .htaccess la entrada de parámetros, en este caso, el id sólo puede ser un número entre 0 y 9, por lo que no podremos escribir nada del estilo:

http://miweb.com/listado_de_noticias/30+and+1=1

Otro caso diferente sería cuando la inyección no se realiza en un valor numérico, por ejemplo:

RewriteRule ^listado_de_noticias/([a-zA-Z0-9]+) noticia.php?id=$1 [L,NC]

En este caso, nos permite introdudir números y letras, pero tampoco podríamos inyectar código SQL ya que ni el espacio ni las comillas están permitidos:

http://adrianreamirez.es/listado_de_noticias/titulo’+and+’1′=’1

En resumen, todo varía en función de cómo esté configurado el .htaccess, al que por supuesto no tenemos acceso. Pero eso no es todo. Muchos administradores piensan que con esto la web ya está protegida a ataques de inyección SQL pero realmente el mod_rewrite es sólo una máscara ya que si el fichero PHP final (noticia.php en este caso) tenía problemas de inyección, los seguirá teniendo. Y si alguien llega a averiguar el nombre del fichero original, podrá acceder directamente sin necesidad de pasar por el mod_rewrite.

Sólo hay que echarle un poco de imaginación. Por ejemplo, buscar nombres similares a ver si hay suerte. Si la url es  http://adrianreamirez.es/listado_de_noticias/30 se pueden realizar búsquedas a ver si hallamos la página original:

http://adrianreamirez.es/listado_de_noticias.php?id=30

http://adrianreamirez.es/noticias.php?id=30

http://adrianreamirez.es/noticias.php?idnoticia=30

…..

Aunque parezca un trabajo de chinos, muchas veces da resultado.

Y si el mod_rewrite se ha aplicado sólo por mantener la seguridad (o mejorar el posicionamiento) y no viene unido a un cambio de estética o remodelación de la web, lo más probable es que podamos encontrar el nombre de algún fichero original mediante otras técnicas, por ejemplo:

  • Buscando en Google y demás buscadores un listado de las páginas indexadas de esa web, con la búsqueda:  ‘site:miweb.com inurl:.php’. Esto nos puede mostrar páginas antiguas que aún sigan indexadas.
  • Buscando con un spider el contenido de cada página de la web. Muchas veces se olvida cambiar una URL para que apunte a la nueva dirección en lugar de al fichero PHP
  • Buscando en Google enlaces hacia esa web, donde es posible que un link antiguo apunte a una noticia o cualquier otra sección de la web, con la búsqueda: ‘link:miweb.com’ o bien: site:.com “miweb.com” -site:miweb.com
  • Buscando en WayBack Machine, que guarda un histórico de muchísimas webs (150 billones … casi nada jeje) y además suele guardar una captura de toda la web cada mes, por lo que muy probablemante escontremos la estructura antigua.

Configurando .htaccess para proteger nuestro servidor.

Aquí os dejo varios tips. Fruto del tiempo libre y sin mujer que lo ocupe:

Tip1:
Bloquear a los Bot’s mas conocidos para evitar el consumo innecesario de ancho de banda

tip2:

Si no nos gusta que nos visiten desde un proxy,  lo que hace es simple detecta a un visitante que proviene de un servidor proxy y lo que hace es darle un white screen

 

#Simple .htaccess Proxy Blocker Mod
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:VIA}       !^$ [OR] RewriteCond %{HTTP:FORWARDED}   !^$ [OR] RewriteCond %{HTTP:USERAGENT_VIA}  !^$ [OR] RewriteCond %{HTTP:X_FORWARDED_FOR}  !^$ [OR] RewriteCond %{HTTP:PROXY_CONNECTION}  !^$ [OR] RewriteCond %{HTTP:XPROXY_CONNECTION}  !^$ [OR] RewriteCond %{HTTP:HTTP_PC_REMOTE_ADDR} !^$ [OR] RewriteCond %{HTTP:HTTP_CLIENT_IP}      !^$
RewriteRule ^(.*)$ - [F] </IfModule>
#Simple .htaccess Proxy Blocker Mod

——————————————————————————-

tip3:

clasico LimitRequestBody; su función es simple, lo que hace es limitar «tanto la descarga como la subida» en cantidad de kilobytes.

#1 megabyte
LimitRequestBody 1024
#10 megabytes
LimitRequestBody 10240
#100 megabytes
LimitRequestBody 102400

—————————————————————

Tip4:

Options All -Indexes evitara que se listen tus archivo cuyas carpetas no tengan index(trabaja de la mano con ErrorDocument)

Options All -Indexes

Caso de IndexIgnore * e comprobado que perjudica de cierta manera al SEO, por lo cual prefiero utilizarlo de esta manera IndexIgnore *. extensión, siguiendo el ejemplo anterio

IndexIgnore *.swf

bloqueo la indexacion de todos los archivos swf, tanto del directorio y sub-directorios, donde se aloje el .htaccess

—————————————————————————

Tip5:

Evitando el intento de manipulación malintencionada de la URL evitaremos La solicitud de método, que se suministra en el REQUEST_METHOD , Si el script en este caso del atacante intenta hacer peticiones por el método que no admitimos deberá ser rechazarlo con un error.

#para nuestro ejemplo solo intentaremos que no se visualice nada
#es decir aremos un white screen (pantallita blanca), como siempre aremos una sola consulta usando un array

RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC] RewriteRule ^(.*)$ - [F,L]

———————-

o también puedes optar por darle algo visual de que su intento «tan primitivo» de hacking no tuvo exito agregando una ruta hacia un archivo o imagen cual sea el caso .

RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC] RewriteRule ^(.*)$ http://midominio.com/intento-de-requets.php  [F,L]

—————————————————

Explicaré por que  solo se usa 4 métodos de los que muchos que hay.
HEAD = evitar requets de la cabeceras
TRACE = evitemos que nos escaneen el sitio, para los veteranos programando en consola como yo, es como utilizar un print trace, para debugear código (en este caso seria pintar un mapa de tu sitio web)
DELETE = su mismo nombre lo dice es mas que obvio :S
TRACK = son métodos HTTP que se utilizan para depurar las conexiones del servidor web Se ha demostrado que los servidores que soportan este método están sujetos a ataques a través de secuencias de comandos del sitio, llamado XST «Cross Site Tracing», son deficientes en los navegadores. especialmente en el mozilla «ups creo que ese dato no lo debí de dar»
Un atacante puede utilizar este error para engañar a los usuarios de una web con el propósito de apoderar se de credenciales(datos importantes). Solución Viable: Des-habilitar estos métodos.

————————————————————————–

TIP (perdí la cuenta)

Mostrar un error HTTP de una manera amigable al visitante (para nuestro ejemplo solo usaremos los mas comunes)

ErrorDocument 401 /errorpage401.php
ErrorDocument 404 /errorpage404.php
ErrorDocument 403 /errorpage403.php
ErrorDocument 500 /errorpage500.php

——————-

Tip7:

Evitar esos desagradables errores de php que tan mala imagen dan a nuestras web o las de nuestros clientes con una de las lineas de código que mas me gusta, cuya función es la de deshabilitar la visualización de todos los errores, no recomendable en modo de desarrollo.

php_flag display_errors off

———————————————————————————————————

Tip8:

# Protegerse contra los ataques DOS limitando el tamaño de subida de archivos
LimitRequestBody 10240000

Tip9:

Tip10:

# Evitar escaneos y cualquier intento de manipulación malintencionada
# de la URL. Con esta regla es imposible lanzar ataques de inyección (SQL, XSS, etc)
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(-|.|’) [OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)(<|>|%3C|%3E)(.*) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget)(.*) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)(libwww-perl|libwwwperl|snoopy|curl|wget|winhttp|python|nikto|scan|clshttp|archiver|loader|email|harvest|fetch|extract|grab|miner|suck|reaper|leach)(.*) [NC,OR]

RewriteCond %{REQUEST_URI} ^(/,|/;|/<|/>|/’|/`|/%2C|/%3C|/%3E|/%27|/////) [NC,OR]
RewriteCond %{HTTP_REFERER} ^(.*)(%00|%08|%09|%0A|%0B|%0C|%0D|%0E|%0F|%2C|<|>|’|%3C|%3E|%26%23|%27|%60)(.*) [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%00|%08|%09|%0A|%0B|%0C|%0D|%0E|%0F|%2C|%3C|%3E|%27|%26%23|%60)(.*) [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(‘|-|<|>|,|/|\\|\.a|\.c|\.t|\.d|\.p|\.i|\.e|\.j)(.*) [NC,OR]
RewriteCond %{HTTP_COOKIE} ^(.*)(<|>|’|%3C|%3E|%27)(.*) [NC]
RewriteRule ^(.*)$ error.php [NC]

 

Otra cosa:

Explicación de lo más básico sobre el módulo rewrite, se que debería de ir al principio, pero bueno:

La sintaxis de RewriteCond es como sigue:

STRING debe ser una variable del servidor o una referencia anterior a alguna RewriteCond.
CONDITION puede ser una expresión regular, similar a una RewriteRule. Además puede tener variantes especiales sobre las expresiones regulares estándar.

Cómo encaja todo esto en nuestas RewriteRule? Si colocas un RewriteCond antes de RewriteRule, la RewriteRule sólo se procesará cuando la RewriteCond sea evaluada como true (esto es, si se cumple la CONDITION).

Y ya vale de teoría. Hagamos algo práctico para evitar que ciertas direcciones IP accedan a nuestro servidor.

Es un ejemplo bastante simple. Si la IP del visitante es 123.45.67.89, a éste se le muestra una página de baneo.

 

 

403 Forbidden y el módulo rewrite

Llevo dos días con un FORBIDDEN en la pantalla, luego de adquirir un script original con todas sus licencias.

Al parecer en el mundo del scpirting manejan los permisos y redirecciones con el rewrite.

El tema que parte del código fuente que adquirí viene encriptado por lo que tampoco puedo modificarlo, a no ser que quiere invertir mis próximos meses luchando contra código en php.-

Al parecer el problema es de mi servidor apache. Y no logro configurar correctamente el Forbidden,

 

Forbidden

You don’t have permission to access / on this server.

Ya las seguiré contando….