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.

Ver código
  1. <?php
  2.     if(!empty($_SERVER['HTTP_CLIENT_IP']))
  3.     {
  4.       echo $_SERVER['HTTP_CLIENT_IP'];
  5.     }
  6.     elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))
  7.     {
  8.       echo $_SERVER['HTTP_X_FORWARDED_FOR'];
  9.     }
  10.     else
  11.     {
  12.       echo $_SERVER['REMOTE_ADDR'];
  13.     }
  14. ?>


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.

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

Publicado en Código en Joomla

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:


Ver código
  1. 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
  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)"
  3. 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
  4. mation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)"
  5. 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
  6. 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:

Ver código
  1. include_once(CLASSPATH.'ps_communication.php');
  2.  
  3.  
  4. $vm_mainframe->addStyleSheet( 'templates/'. $mainframe->getTemplate() );
  5.  
  6.  
  7. if( empty( $_POST['submit'] ) || !$ok ) {
  8.         $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
  9.         echo '<h3>'.$VM_LANG->_('VM_RECOMMEND_FORM_LBL').'</h3>';
  10.  
  11.  
  12.         ps_communication::showRecommendForm($product_id);
  13. }
  14. else {
  15.         $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
  16.         echo '<span class="contentheading">'. $VM_LANG->_('VM_RECOMMEND_DONE').' '. shopMakeHtmlSafe(vmGet($_POST,'recipient_mail')).'</span> <br />
  17.                 <br />
  18.                 <br />
  19.                 <a href="javascript:window.close();">
  20.                 <span class="small">'. $VM_LANG->_('PROMPT_CLOSE') .'</span>
  21.                 </a>';
  22.  
  23.  
  24. }

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.

Publicado en Seguridad

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.

Ver código
  1. #!/bin/bash
  2.  
  3. echo "Actualizando file.php....."
  4.  
  5. md5sum */htdocs/libraries/joomla/filesystem/file.php|while read x
  6. do
  7. m5="`echo $x|awk '{print $1}'`"
  8. file="`echo $x|awk '{print $2}'`"
  9. if [ "$m5" == "7a06b1674f30d36521f4755f3438acaf" ]
  10. then
  11. #cp file.php $file
  12. echo "$file -> Actualizado"
  13. else
  14. if [ "$m5" == "0eabdf91e2c7a26493eeb3dbe7a3fb39" ]
  15. then
  16. echo "$file -> Actualizado"
  17. else
  18. echo "$x -> Version desconocida"
  19. fi
  20. fi
  21. done
  22.  
  23. echo
  24. echo
  25. echo "Actualizando media.php....."
  26.  
  27. md5sum */htdocs/administrator/components/com_media/helpers/media.php|while read x
  28. do
  29. m5="`echo $x|awk '{print $1}'`"
  30. file="`echo $x|awk '{print $2}'`"
  31. if [ "$m5" == "8ee5fd1f0d70d0a3b00006aa35267afe" ]
  32. then
  33. #cp media.php $file
  34. echo "$file -> Actualizado"
  35. else
  36. if [ "$m5" == "3de2ea3338d49956b5dabf3a3fa1200d" ]
  37. then
  38. echo "$file -> Actualizado"
  39. else
  40. echo "$x -> Version desconocida"
  41. fi
  42. fi
  43. done
  44.  

 

 icon joomla_1526patch.zip (5.92 kB)

 

Referencias:

Publicado en Seguridad

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.

Publicado en Blog
Domingo, 12 Mayo 2013 12:02

Protege tu Joomla contra los hackers

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.

icon Descarga script (2.05 kB)

Ver código
  1. #!/bin/sh
  2.  
  3. dir="/var/www/$1/htdocs"
  4.  
  5. if [ ! "$1" ]
  6. then
  7. echo "falta el nombre del dominio"
  8. exit 1
  9. fi
  10.  
  11. if [ ! -d $dir ]
  12. then
  13. echo "no existe el dominio"
  14. exit 1
  15. fi
  16.  
  17. cd $dir
  18.  
  19. chmod ogu-w $dir
  20. chmod ogu-w -R administrator components includes language libraries modules plugins templates
  21. chmod ogu-w *.php
  22.  
  23. # Permisos para joomla =1.0
  24. if [ -d editor ]
  25. then
  26. chmod ogu-w -R editor
  27. fi
  28. if [ -d mambots ]
  29. then
  30. chmod ogu-w -R mambots
  31. fi
  32.  
  33. # Permisos para joomla =1.5
  34. if [ -d xmlrpc ]
  35. then
  36. chmod ogu-w -R xmlrpc
  37. fi
  38.  
  39. # Permisos para joomla >=1.6
  40. if [ -d cli ]
  41. then
  42. chmod ogu-w -R cli
  43. fi
  44.  
  45. # Permisos para joomla >=3.0
  46. if [ -d bin ]
  47. then
  48. chmod ogu-w -R bin layouts
  49. fi
  50.  
  51. chmod ogu+w -R administrator/cache
  52.  
  53. if [ -d administrator/backups ]
  54. then
  55. chmod ogu+w -R administrator/backups
  56. fi
  57.  
  58. # Ajusta permisos para virtuemart 1.5.x
  59. if [ -d components/com_virtuemart/shop_image ]
  60. then
  61. chmod ogu+w -R components/com_virtuemart/shop_image
  62. fi
  63. if [ -e administrator/components/com_virtuemart/virtuemart.cfg.php ]
  64. then
  65. chmod ogu+w -R administrator/components/com_virtuemart/virtuemart.cfg.php
  66. fi
  67.  
  68.  
  69. # Ajusta permisos para rsform
  70. if [ -d components/com_rsform/uploads ]
  71. then
  72. chmod ogu+w -R components/com_rsform/uploads
  73. fi
  74.  
  75.  
  76. # Ajusta permisos para docman
  77. if [ -e administrator/components/com_docman/docman.config.php ]
  78. then
  79. chmod ogu+w -R administrator/components/com_docman/docman.config.php
  80. fi
  81.  
  82.  
  83. # Ajusta permisos para sef404
  84. if [ -d administrator/components/com_sh404sef/config ]
  85. then
  86. chmod ogu+w -R administrator/components/com_sh404sef/config
  87. fi
  88. if [ -d components/com_sh404sef/cache ]
  89. then
  90. chmod ogu+w -R components/com_sh404sef/cache
  91. fi
  92.  
  93.  
  94. # Ajusta permisos para akeeba
  95. if [ -d administrator/components/com_akeeba/backup ]
  96. then
  97. chmod ogu+w -R administrator/components/com_akeeba/backup
  98. fi
  99.  
  100.  
  101. # Ajusta permisos para extplorer
  102. if [ -d administrator/components/com_extplorer/config ]
  103. then
  104. chmod ogu+w -R administrator/components/com_extplorer/config
  105. fi
  106.  
  107.  
  108. # Ajusta permisos para breezingforms
  109. if [ -d administrator/components/com_breezingforms/ajax_cache ]
  110. then
  111. chmod ogu+w -R administrator/components/com_breezingforms/ajax_cache
  112. fi
  113. if [ -d administrator/components/com_breezingforms/payment_cache ]
  114. then
  115. chmod ogu+w -R administrator/components/com_breezingforms/payment_cache
  116. 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.
Publicado en Joomla

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.

Comparativa joomla 2.5 3.0 y XCache

  Joomla 2.5 Joomla 3.0
PHP 5.3 38,529 34,050
PHP 5.4 37,235 33,353
PHP 5.3 + Xcache 30,356 26,836
PHP 5.4 + Xcache 28,680 25,763
PHP 5.3 + Xcache + Cache Conservacional 28,086 25,014
PHP 5.4 + Xcache + Cache Conservacional 26,364 23,881
PHP 5.3 + Xcache + Cache Progresiva 20,852 19,469
PHP 5.4 + Xcache + Cache Progresiva 20,508 19,307

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/

Publicado en Código en Joomla
Martes, 11 Diciembre 2012 01:41

Como mejorar la seguridad de tu web en Joomla

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 usuariosj15nuevosusuarios

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

 

Publicado en Código en Joomla
Lunes, 10 Septiembre 2012 22:13

Joomla 1.5 y el error de mail TLS

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.

 

 

joomla15tls2

 

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.

Ver código
  1. fsockopen("ssl://smtp.gmail.com", 465, $errNum, $errStr, 30); // Correcto
  2.  
  3. fsockopen("tls://smtp.gmail.com", 587, $errNum, $errStr, 30); // Error SSL3_GET_RECORD

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

Publicado en Joomla