Normalmente en un servidor web normal del tipo apache, nginx o similares para descubrir desde cual IP nos están accediendo a la web, con obtener el valor de la variable de estándar 'REMOTE_ADDR' nos dará el valor correcto. Pero esto no siempre es cierto, puede suceder que se haya implementado en el servidor una cache para mejorar el rendimiento y el posicionamiento SEO por reducir el tiempo de respuesta, activando un Proxy inverso (Reverse Proxy) o un balanceador de carga con keealived, con esto conseguimos que las paginas o ficheros mas utilizados sean almacenados en una cache en memoria mejorando sustancialmente el tiempo de respuesta, nosotros utilizamos SQUID como cache para dicho propósito pero existen otras igual de efectivas como varnish o incluso nginx.

Con modificar nuestra programación PHP con estas simples lineas podemos controlar también cuando la IP pasa a través de un PROXY.

<?php
    if(!empty($_SERVER['HTTP_CLIENT_IP']))
    {
      echo $_SERVER['HTTP_CLIENT_IP'];
    }
    elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))
    {
      echo $_SERVER['HTTP_X_FORWARDED_FOR'];
    }
    else
    {
      echo $_SERVER['REMOTE_ADDR'];
    }
?>

Existen casos especiales como en virtuemart 2.0 que el sistema de pago paypal genera un error por detectar de forma incorrecta la IP de origen:

Error code 506. Possible fraud. Error with REMOTE IP ADDRESS = 127.0.0.1.
The remote address of the script posting to this notify script does not match a valid PayPal ip address

En INODE64 hemos realizado un pequeño parche que soluciona este problema. Ya lo hemos reportado en el foro, pero aun la versión 2.6.6 aun no lo tiene aplicado.

 paypal_proxy.diff (2.9 kB 2014-07-20 00:01:35)

Recientemente unos de nuestros servidores se disparo una alarma por incremento de mensajes en cola. Cuando empezamos la búsqueda del origen del envió masivo, nos dimos cuenta que se realizaba desde una web en Joomla con Virtuemart 1.1.7, al repasar el registro de acceso del apache aparecian unos miles de accesos por POST similares a estos:

112.207.247.13 - - [13/Mar/2014:23:08:14 +0100] "POST /index2.php HTTP/1.1" 200 1731 "http://xxxxx.xxxxx.com/index2.php?page=shop.recommend&product_id=283&pop=1&tmpl=component&option=com_virtuemart&Itemid=2 
9" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; iOpus-Web-Automation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)" 
112.207.247.13 - - [13/Mar/2014:23:08:15 +0100] "GET /templates/theme137 HTTP/1.1" 301 325 "http://xxxxx.xxxxx.com/index2.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; iOpus-Web-Auto 
mation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)" 
112.207.247.13 - - [13/Mar/2014:23:08:15 +0100] "POST /index2.php HTTP/1.1" 200 1750 "http://xxxxx.xxxxx.com/index2.php?page=shop.recommend&product_id=283&pop=1&tmpl=component&option=com_virtuemart&Itemid=2 
9" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; iOpus-Web-Automation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)"

Para solucionar el problema hay que editar el fichero:

/administrator/components/com_virtuemart/html/shop.recommend.php

y eliminar el siguiente código:

include_once(CLASSPATH.'ps_communication.php');
 
 
$vm_mainframe->addStyleSheet( 'templates/'. $mainframe->getTemplate() );
 
 
if( empty( $_POST['submit'] ) || !$ok ) {
        $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
        echo '<h3>'.$VM_LANG->_('VM_RECOMMEND_FORM_LBL').'</h3>';
 
 
        ps_communication::showRecommendForm($product_id);
}
else {
        $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
        echo '<span class="contentheading">'. $VM_LANG->_('VM_RECOMMEND_DONE').' '. shopMakeHtmlSafe(vmGet($_POST,'recipient_mail')).'</span> <br />
                <br />
                <br />
                <a href="javascript:window.close();">
                <span class="small">'. $VM_LANG->_('PROMPT_CLOSE') .'</span>
                </a>';
 
 
}

El código anterior permite una suplantación de identidad y que servicios de email spoofing aprovechen esta vulnerabilidad para sus “clientes”.

Ya no se podrán realizar recomendaciones, pero al menos los atacantes tampoco.
Como solución mas elegante se podría activar el recaptcha, pero lo mejor es que migre el cliente a Virtuemart 2.0

Al principio no hemos encontrado ninguna referencia, pero si que existe reporte del problema desde el 2010, lo grave del asunto es que hayan pasado 4 años no se informe a la gente ni se cree una versión con parche desde virtuemart para solucionarlo.

• https://forum.virtuemart.net/index.php?topic=72804.0

Nada mas recibir la notificación de este serio problema de seguridad (la cual permite subir ficheros al servidor) que afecta a la versión de Joomla 1.5.xx empece a revisar el código y planificar las actualizaciones a los clientes alojados en los diferentes servidores.

Pero por desgracia no todos los clientes han migrado a las versiones mas recientes y el numero de ellos no es pequeño, con lo cual prepare un pequeño script que los actualiza solo aquellos que estén afectados por el problema.

Ajunto el script, en caso necesario es fácil cambiar la ruta donde se encuentras los dominios alojados.

#!/bin/bash
 
echo "Actualizando file.php....."
 
md5sum */htdocs/libraries/joomla/filesystem/file.php|while read x
do
    m5="`echo $x|awk '{print $1}'`"
    file="`echo $x|awk '{print $2}'`"
    if [ "$m5" == "7a06b1674f30d36521f4755f3438acaf" ]
    then
        #cp file.php $file
        echo "$file -> Actualizado"
    else
        if [ "$m5" == "0eabdf91e2c7a26493eeb3dbe7a3fb39" ]
        then
            echo "$file -> Actualizado"
        else
            echo "$x -> Version desconocida"
        fi
    fi
done
 
echo
echo
echo "Actualizando media.php....."
 
md5sum */htdocs/administrator/components/com_media/helpers/media.php|while read x
do
    m5="`echo $x|awk '{print $1}'`"
    file="`echo $x|awk '{print $2}'`"
    if [ "$m5" == "8ee5fd1f0d70d0a3b00006aa35267afe" ]
    then
        #cp media.php $file
        echo "$file -> Actualizado"
    else
        if [ "$m5" == "3de2ea3338d49956b5dabf3a3fa1200d" ]
        then
            echo "$file -> Actualizado"
        else
            echo "$x -> Version desconocida"
        fi
    fi
done
 

  joomla_1526patch.zip (5.92 kB)

Referencias:

• Joomla 1.5 security patch made easy to install
• Joomla Bug [#31626] Unauthorized file upload security issue

Buscamos un perfil de programador WEB en PHP

Requisitos:

• Programación en PHP

• Ultimas tecnologías web HTML5, CSS3, Jquery, AJAX

• Vivir en las proximidades de Vila-real

Se valorara:

• Conocimientos de Joomla

• Vehículo propio

• Linux

Ofrecemos:

• Contratación inmediata

• Formación continua

No envías el Curriculum Viate indicando “Programador WEB” en las notas

http://www.inode64.com/oferta-de-empleo

Para poder agilizar el proceso de selección hemos ideado un pequeño test antes de la entrevista personal, ya que la ultima selección de personal recibimos bastantes ofertas y muchas de ellas eran personas que no sabían ni programar.

Consiste en coger el código de uno de nuestros scripts y añadir una funcionalidad (añadir el soporte para modulo o de plugin) encontrar un bug o cualquier otra cosa.

http://www.inode64.com/codigo/joomla/componente-content_fake-para-la-creacion-de-contenidos-falsos

Luego seria enviar el código y explicar los cambios, como se ha realizado, tu valoración, etc...

Se valorara tanto la claridad, simpleza y las tecnologías utilizadas.

Realmente tienes que intentar demostrar tus mejores habilidades y la agilidad de comunicar tus ideas ante un reto desconocido.

Después de realizar un website con Joomla si el cliente no necesita añadir nuevas funcionalidades o no puede actualizar los módulos, componentes o plugins porque se ha quedado desactualizada, suele suceder que empiezan a encontrarse numerosas vulnerabilidades que son aprovechadas para acceder al código para manipularlo, enviar emails, mostrar otros productos, infectar a los visitantes o atacar a otras webs.

Ante este panorama, sí el cliente no esta dispuesto a realizar cambios y a realizar una pequeña inversión en subsanarlos nos vemos avocados recibir todo tipo de ataques.

Para solucionar este problema existe varias soluciones, una de ellas que es fácilmente aplicable, simplemente es proteger el espacio web contra escritura, ya qué muchos ataques se basan en modificar los ficheros index.php , template.php, footer.php, etc... y con añadir solamente la escritura en las zonas, donde sea necesario para el correcto funcionamiento del Joomla, solucionamos muchos quebraderos de cabeza.

Hemos realizado un pequeño script en bash que tiene en cuenta las versiones de Joomla1.0 hasta la 3.1 y los habituales componentes que escriben en partes especiales como el docman, akeeba, virtuemart 1.5.x, sef404, extplorer, breezingforms.
Con esto el cliente podrá continuar trabajado con su web añadiendo nuevos artículos, recibiendo información de los formularios, etc.. pero no podrá ni instalar nada nuevo ni modificar archivos css ni php. En caso necesario se tendría que habilitar la escritura en esos archivos pero limitandolo para que a los atacantes les cueste más y que desistan e intente atacar a otra web menos protegida.

 Descarga script (2.05 kB)

#!/bin/sh
 
dir="/var/www/$1/htdocs"
 
if [ ! "$1" ]
then
    echo "falta el nombre del dominio"
    exit 1
fi
 
if [ ! -d $dir ]
then
    echo "no existe el dominio"
    exit 1
fi
 
cd $dir
 
chmod ogu-w $dir
chmod ogu-w -R administrator components includes language libraries modules plugins templates
chmod ogu-w *.php
 
# Permisos para joomla =1.0
if [ -d editor ]
then
    chmod ogu-w -R editor
fi
if [ -d mambots ]
then
    chmod ogu-w -R mambots
fi
 
# Permisos para joomla =1.5
if [ -d xmlrpc ]
then
    chmod ogu-w -R xmlrpc
fi
 
# Permisos para joomla >=1.6
if [ -d cli ]
then
    chmod ogu-w -R cli
fi
 
# Permisos para joomla >=3.0
if [ -d bin ]
then
    chmod ogu-w -R bin layouts
fi
 
chmod ogu+w -R administrator/cache
 
if [ -d administrator/backups ]
then
    chmod ogu+w -R administrator/backups
fi
 
# Ajusta permisos para virtuemart 1.5.x
if [ -d components/com_virtuemart/shop_image ]
then
    chmod ogu+w -R components/com_virtuemart/shop_image
fi
if [ -e administrator/components/com_virtuemart/virtuemart.cfg.php ]
then
    chmod ogu+w -R administrator/components/com_virtuemart/virtuemart.cfg.php
fi
 
 
# Ajusta permisos para rsform
if [ -d components/com_rsform/uploads ]
then
    chmod ogu+w -R components/com_rsform/uploads
fi
 
 
# Ajusta permisos para docman
if [ -e administrator/components/com_docman/docman.config.php ]
then
    chmod ogu+w -R administrator/components/com_docman/docman.config.php
fi
 
 
# Ajusta permisos para sef404
if [ -d administrator/components/com_sh404sef/config ]
then
    chmod ogu+w -R administrator/components/com_sh404sef/config
fi
if [ -d components/com_sh404sef/cache ]
then
    chmod ogu+w -R components/com_sh404sef/cache
fi
 
 
# Ajusta permisos para akeeba
if [ -d administrator/components/com_akeeba/backup ]
then
    chmod ogu+w -R administrator/components/com_akeeba/backup
fi
 
 
# Ajusta permisos para extplorer
if [ -d administrator/components/com_extplorer/config ]
then
    chmod ogu+w -R administrator/components/com_extplorer/config
fi
 
 
# Ajusta permisos para breezingforms
if [ -d administrator/components/com_breezingforms/ajax_cache ]
then
    chmod ogu+w -R administrator/components/com_breezingforms/ajax_cache
fi
if [ -d administrator/components/com_breezingforms/payment_cache ]
then
    chmod ogu+w -R administrator/components/com_breezingforms/payment_cache
fi

• Como mejora suplementaria, sí el cliente no necesita añadir ninguna imagen nueva también se puede proteger todo el directorio /images
• Como existen infinidad de módulos, componentes y configuraciones en caso de encontrar algún componente que no funcione, enviadnos para incluirlo.

Hemos usado como banco de pruebas gk_magazine un template de Gavick que se encuentra optimizado tanto para Joomla 2.5 como 3.0 para intentar ser los mas justos posible y usando en los dos casos el quickstart para que en contenido de la pagina principal tuviera un contenido mas parecido a una web real.

En conclusión vemos que es un poco mas rápida la versión de Joomla 3.0 pero esa diferencia es imperceptible cuando se activa la cache progresiva. Algo similar sucede con PHP 5.4 donde el aumento de velocidad no es muy significativo, donde lo más destacado es usar un sistema de cache para PHP como son XCache o APC, pero este ultimo nos ha dado algún problema y lo hemos tenido que reemplazar en nuestros servidores de producción.

Sistema de evalucion usado:

PHP 5.3.23
PHP 5.4.13


Version Xcache 3.0.1
Version Joomla 2.5.9
Version joomla 3.0.3
Apache 2.2.24

kernel 3.7.10 64bits
GCC 4.5.4
Sistema de archivos EXT4
Procesador AMD Athlon(tm) II X2 255 Processor
Memoria ram de 2Gb
Placa Base Gigabyte GA-MA785GMT-UD2H
XCache de 1G


ab -n 200 -c 5 http://localhost/j25/
ab -n 200 -c 5 http://localhost/j30/

Muchas veces caemos en la falsa sensación que los ataques de seguridad y el malware es una cosa muy lejana, nada mas lejos de la realidad, los hackers y compañía no paran de mejorar sus métodos de infección y de búsqueda de sites vulnerables para instalar programas de envió de SPAM, capturar contraseñas, infectar a los navegadores, etc.., tanto en CMS (Joomla, Wordpress, Drupal, etc...) como en software desarrollado a medida.
Existen unas reglas básicas y obvias que podemos seguir para limitar que nuestro website sea presa de manos no deseables.

1. Contraseñas

   Es obvio pero las contraseñas tienen que tener un grado de complejidad que no se encuentren fácilmente en sistemas de diccionarios y también cambiarla periódicamente. No hace falta que sea cada semana pero como mínimo de 6 meses.

2. Limitar el acceso a /administrator/

   Existes sistemas para bloquear por IP, países o regiones y así en caso de que caigan en malas manos la contraseña de acceso al backend esta no puede ser usada en un primer momento, nos da tiempo a cambiarla y limitar la maleza que puedan realizar.

3. Refactorización

   Limpiar y eliminar componentes, módulos y plugins no necesarios, esto nos permitirá limitar en lo posible la aparición de agujeros de seguridad a lo largo del tiempo y simplificar las actualizaciones.

4. Actualizar

   Tener instaladas las ultimas actualizaciones, esto no es garantía al 100% pero si que nos eliminara la posibilidad de código antiguo y ya conocido como vulnerable.

5. Bloqueo website

   Si tu negocio es local, regional o de un solo país, se puede bloquear para que por ejemplo solo se puede consultar desde una lista de países permitidos, o también se puede poner una lista negra (rusia y china, por ejemplo), que no se traducirán en conversiones ni de clientes ni monetarias para nosotros. Esto también mejora el rendimiento para poder eliminar consultas y carga innecesaria. Nos baraja la estadísticas pero mejorara la calidad y usuarios que navegan por ella.

6. Comentarios

   Si no vas ha realizar una web social desactiva los comentarios, la impresión, el reenvió por email, etc.. que puede dejar el camino para que usen tu web como envió de SPAM. En caso de usarlos activar un sistema de captcha para no ser inundados con mensajes basura y SPAM.

7. Envió de correo SMTP
   

   Esto depende de las políticas de seguridad implementadas en el hosting pero lo mejor "por experiencia" es crear una cuenta de correo por cada website y en la configuración del Joomla o cualquier otro programa usar el envió a través de una conexión segura (TLS o SSL) y con autenticación. Eliminamos el envió del comando mail de php que es la principal forma que tienen los atacantes de enviar SPAM usando nuestro servidor y en caso de tener una web comprometida es fácil saber en que dominio.

8. Registro de usuarios

   Es habitual encontrar en website activado el registro de nuevos usuarios, mientras que el site no sea de E-Commercer o sea un requisito, no le pongamos la vida fácil a los hackers dándoles mas acceso que podría ser usado para escalar privilegios. Para desactivar simplemente sigue los pasos siguientes:

   Joomla 1.5 ve a la pestaña Sitio, Configuración Global, Sistema y pon que no en la opción “Permitir el registro de usuarios”

   Joomla 2.5 y posteriores, ir a Gestor de usuarios, pulsar en opciones y desactivar el “Permitir el registro de usuarios”

En la versión de Joomla 1.5 se usa para enviar el correo electrónico el script phpmailer 2.0.4 del 2009, esta versión en concreto no funciona el envió de correo si se selecciona en la Configuración global, TLS en SMTP Security. Y por otra, los grandes ISP (google, outlook, etc.. ) obligan a usar encriptación para enviar emails autenticados, con lo cual nos aparece en la pantalla del navegador el mensaje de Joomla.

¡Error SMTP! No puedo conectar al hospedaje SMTP.

Tanto desde el frontend como desde el backend

La solución consiste en activar la seguridad SSL y poner el puerto 465

Realmente el problema es de la forma que usa phpmailer la conexión del socket.

fsockopen("ssl://smtp.gmail.com", 465, $errNum, $errStr, 30); // Correcto
 
fsockopen("tls://smtp.gmail.com", 587, $errNum, $errStr, 30); // Error SSL3_GET_RECORD

Mirar este ejemplo mas descriptivo de la correcta implementación TLS.