Os dejo aquí el PDF que puse en charla sobre Seguridad en comercios electrónicos de C0r0n4con Christmas Edition 2020. Si tenéis alguna duda, no dudéis en poneros en contacto a través de la página de contacto, o en RRSS y os responderemos a la máxima brevedad.
Descarga el archivo «Seguridad en ecommerce. C0r0n4con 2020»
Author: Silvia Suria Torres
Hemos actualizado recientemente unas cuantas plataformas de Mautic, de la versión 2 a la 3, y en todas ha terminado pasando lo mismo: necesitaba actualizarse por línea de comandos, y hemos tenido que forzarla, es decir, actualizar la base de datos por un lado y el código por otro, lanzando para ello varias veces upgrade_v3.php –ignore-warnings y limpiando entre uno y otro la caché mediante línea de comandos, y restaurando permisos en las carpetas y archivos.
Si estáis en esta tesitura, os recomiendo que miréis antes de desesperaros el archivo de errores que está en var/logs del propio Mautic, y os dará una pista de qué le está ocurriendo.
Por otro lado, una vez habéis conseguido pasar a la versión 3, os recomiendo que sigáis actualizando (ya estas versiones sí pueden actualizarse a través de la plataforma, sin necesidad de usar la línea de comandos), ya que la última versión corrige muchos pequeños errores de la versión 3.0 y 3.1.
Por último, comentaros que si al entrar en el panel de configuración de Mautic e intentar aplicar los cambios, os devuelve un error como este:
mautic.core.update.archive_no_such_file
La solución es muy simple: id a var/cache y veréis que el directorio prod no tenga los permisos, o usuario o grupo correcto. Corregidlo y todo irá bien.
En este blog no somos de realizar largos y sesudos artículos, no obstante, en este caso es necesario explicar un proceso largo y nada intuitivo, por lo que se impone romper con nuestras reglas y hacer un tutorial extenso, que ayude con un proceso no muy documentado aún.
Hasta principios de 2020, había un procedimiento para descargar y actualizar las bases de datos de GeoLite y GeoIP para Mautic, pero por un cambio en la política de envío de datos de la empresa que mantiene estos datos (Maxmind), ahora debemos realizar unos pasos distintos a los que te explican en la mayoría de las webs del mercado, así que si estás siguiendo algún tutorial y no te funciona, no desesperes, no estará actualizado (mira la fecha del artículo, seguramente será de antes de principios de 2020).
¿Cómo debemos proceder a partir de 2020?
Primero crearemos una cuenta gratuita en Maxmind para descargar GeoLite2. Para este paso, usaremos este enlace:
https://www.maxmind.com/en/geolite2/signup
Una vez que hayas rellenado el formulario, recibirás un correo electrónico de Maxmind, (mira en la carpeta de SPAM si no lo encuentras), y haremos clic en el enlace para crear una contraseña. (Donde pone «first create a password here»). No uses otros enlaces, porque no funcionarán. Una vez creada la contraseña, lógate con ella y busca en el menú de la izquierda el elemento «My License Key». Ahí tendrás un botón para generar la clave de licencia («Generate new license key»). Haz clic en él y sigue los pasos que te indica (poner un nombre a la clave que estás generando) y marca la opción «Generate a licensekey and config file for use with geoipupdate version 3.1.1 or newer». Hacemos clic en «Confirm». Al hacer esto, nos mostrará una vez la clave y el ID de usuario, por lo que deberemos guardar estos datos para poderlos usar después.
Hacemos clic en el botón de «Download Config» y guardamos este archivo también. Lo necesitaremos en el servidor donde tenemos Mautic.
A continuación necesitamos entrar por una terminal al servidor y ejecutar (comandos para Ubuntu):
add-apt-repository ppa:maxmind/ppa
apt update
apt upgrade
apt install geoipupdate
Con estas instrucciones, insertaremos el repositorio en nuestro servidor e instalaremos geoipupdate.
Para poder ejecutar a continuación el script descargado, necesitaremos poner el contenido del archivo .conf que nos descargamos anteriormente en el directorio etc/ del script instalado, en el archivo que se llama GeiIP.conf.*
Llegados a este punto, ya tenemos el script funcionando en nuestro servidor. Ahora tenemos que poder actualizarlo. Para ello, por un lado debemos unir Mautic con lo instalado en el servidor, y por otro, lanzarlo como proceso cron. Vamos a ello.
Lo que primero debemos hacer es irnos al directorio donde está Mautic instalado, y comprobar que existe app/cache/ip_data. Si no existiera, creamos esa ruta, y le damos permisos 775.
Ejecutamos a continuación:
sudo -u daemon geoipupdate -f /etc/GeoIP.conf -d /ruta/de/mautic/app/cache/ip_data -v
Al poner -v (verbose), nos devolverá información sobre el proceso y el resultado del script. Con esto, Mautic ya deberá poder leer la base de datos que intentábamos tener actualizada. Vamos ya por el último punto: ejecutamos crontab -e e insertamos
0 0 * * * sudo -u daemon geoipupdate -f /etc/GeoIP.conf -d /ruta/de/mautic/app/cache/ip_data
Y con esto, todos los días a las 0:00 se ejecutará esta línea, actualizando GeoIP. Y ya está. No tocaremos nada en Mautic, más allá de indicar la ruta de la base de datos, si no es la correcta. Pero no intentaremos actualizarla a través de Mautic, ya que este proceso ya es independiente de Mautic.
*NOTA: para sistemas no Ubuntu, este archivo .conf puede estar en una ruta distinta a /etc. Para averiguarlo, bastará con ejecutar geoipupdate -v y nos mostrará la ruta que buscamos.
Has montado Mautic en un servidor limpio, lo has probado y funciona todo. Estás configurando el correo electrónico, haces la comprobación de conexión, todo va bien. Pero es llegar al envío de prueba del correo, y se queda eternamente pensando, hasta llegar a un error 503 del servidor.
Este error, unido a los mensajes que devuelve el archivo de log del servidor, pueden llevarte a dar vueltas inútilmente.
Por otro lado, el log del propio Mautic (en app/logs), tampoco te va a ayudar mucho:
[2020-09-21 12:00:03] mautic.NOTICE: Symfony\Component\Debug\Exception\FatalThrowableError: Call to undefined function Mautic\EmailBundle\MonitoredEmail\imap_search() (uncaught exception) at /ruta/absoluta/a/mautic/app/bundles/EmailBundle/MonitoredEmail/Mailbox.php line 570 while running console command `mautic:email:fetch` [] []
Realmente este problema lo que está indicando es que muy probablemente tengas que instalar el paquete PHP-Imap. Dependiendo de si usas CentOS o Ubuntu, la instalación puede variar un poco, esto mejor lo buscas según sea tu distro. Y al terminar de instalarlo, recuerda reiniciar Apache (o Nginx) y PHP-FPM si lo estás utilizando.
El ataque a plataformas de WordPress por este tipo de malware ha saltado de forma masiva a principios de septiembre de 2.020. se caracteriza por insertar un código en JavaScript al principio de ciertos archivos de la web y artículos en la base de datos, de manera que la web hackeada redirecciona el tráfico que le llega y lo lleva a una serie de webs ajenas a la web hackeada.
¿Cómo logra penetrar en el sistema?
En principio parece que aprovecha una vulnerabilidad de un plugin, File Manager, aunque esa vulnerabilidad puede estar presente en otros plugins.
¿Cómo lo quito del sistema?
Si tiene una copia de seguridad de antes del ataque, restáurela, instale todas las actualizaciones que necesite el sistema y desinstale aquellos plugins discontinuados y los que sirvan para administrar los archivos de WordPress (sus nombres pueden ser File Manager o similar).
Si no tiene copia, o ésta está infectada también, o la copia no es lo suficientemente actualizada, entonces puede hacer una de estas dos cosas:
1.- Armarse de paciencia y empezar a limpiar código malicioso de la siguiente forma:
Localizar los archivos insertados en el sistema para infectarlo
En el directorio de wp-content/uploads/ habrá probablemente un archivo llamado _lte o lte_ o similar. Y algún archivo que aparentemente sea de WordPress, porque su nombre comenzará por wp- y tendrá extensión .php. Hay que borrarlos. También habría que localizar en el directorio raíz algún archivo añadido a los propios de WordPress.
Limpiar el código
Lo más cómodo es sustituir los directorios w-admin y wp-include de una versión limpia de WordPress que se localice en la web oficial de WordPress. Después se localizarán los archivos modificados recientemente (una técnica fiable para saber cuándo se produjo el ataque es mirar la fecha y hora de index.php, y a partir de ahí, buscar los archivos .js y .php modificados en esa fecha y hora).
Archivos PHP
Una vez localizados los archivos .php modificados, se sustituirá la cadena insertada antes del primer ««. La cadena que encontramos nosotros inicialmente era
aunque la URL puede cambiar.
Archivos JS
En este caso, puede ser que la cadena a insertar sea parecida a esta cadena:
Limpiar la base de datos
Hay que descargar un backup de la tabla de posts y buscar la cadena que hemos visto anteriormente en los archivos .php insertadas, y borrarlas. Después se vuelcan estas líneas modificadas de nuevo con un replace, de forma que todas las líneas quedan sin el script insertado.
2.- O hacer las cosas un poco más rápidas.
Esto sólo puede hacerse sólo si no se han modificado ni plugins ni plantilla, o bien se tienen los códigos originales de lo modificado:
Localizar la cadena insertada mirando el index.php en el directorio raíz.
Limpiar la tabla de posts la base de datos
, como se explica en el apartado anterior y extraer un backup completo.
Realizar una lista de los plugins y la plantilla que tiene instalada
Y si hay un tema hijo, se deberá tener o bien un backup válido o bien, habrá que limpiar el código del tema hijo, como se explica en el punto anterior «Limpiar código»
Limpiar el directorio de imágenes
Haremos un backup de wp-content/uploads y se buscará el archivo _lte o similar para borrarlo, junto con el archivo que comience por wp- en ese directorio, y que no sea propio de WordPress
Borrar la web
Excepto wp-config.php, wp-content/uploads/* y volver a instalar WordPress y los plugins
Si tiene una web hackeada y no sabe recuperarla, podemos ayudarle.
Hace unos años escribimos un artículo sobre cómo generar un archivo DOCX desde el contenido de una página web que podéis consultar en este enlace.
Ahora explicamos cómo imprimir por ejemplo el resultado de una búsqueda específica que hayamos programado en WordPress. En este caso, hicimos un buscador personalizado para un modelo de datos definido con ACF que necesitaba, y al realizar las búsquedas, el cliente quería poder extraer esos datos en listados que obtenía resultado de las búsquedas, con los campos personalizados tal y como se devolvían en la página, con un orden y una agrupación específicos, cosa que los plugins que conocíamos de WordPress no permitían.
Para ello, en la página en la que construíamos el listado hemos insertado un formulario con campos ocultos con un botón visible con el que enviamos la información en html exáctamente que queríamos listar en DOCX. Al hacer clic, ese botón enviará la información a un archivo como el del enlace anterior, en el que se recibe todo el HTML, creando el archivo DOCX con el listado, y simplemente añadimos un poco de estilo para poder mostrar el listado con el mismo diseño.
El código necesario para hacer todo esto es sencillo:
En el archivo donde está el resultado de la búsqueda, creamos:
echo "<form method=post action=archivoParaImprimir.php><input name='contenido' id='contenido' type='hidden' value='".$listadoEnHtml."'><input type='submit' value='DOCX'></form>";
y el archivo que genera el DOCX:
<?php
$contenido = $_POST['contenido'];
header("Content-type: application/vnd.ms-word");
header("Content-Disposition: attachment;Filename=listado.docx");
?>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
<!--
/*aquí ponemos las reglas que queramos, con las clases que tenemos*/
-->
</style>
</head>
<body>
<?php echo $contenido; ?>
</body>
</html>
Fail2ban es una herramienta imprescindible para montar un servidor web hoy en día, si necesitáis saber más sobre ella, este enlace a su Wiki os lo aclara. Pero a veces bloquea a alguien que simplemente se equivoca al teclear una contraseña al intentar acceder al servicio de FTP, SSH o el correo (entrada o salida). Estos son los servicios que principalmente protejo con Fail2Ban y que son susceptibles los clientes de tener problemas con los baneos.
Cuando ocurre que alguien es baneado por escribir mal el usuario/contraseña, la forma más rápida de saber si está o no en lista de baneo es lanzando el comando:
fail2ban-client status | grep "Jail list:" | sed "s/ //g" | awk '{split($2,a,",");for(i in a) system("fail2ban-client status " a[i])}' | grep "Status\|IP list"
Y si aparece la IP del usuario en una lista como:
Status for the jail: dovecot `- Banned IP list:xxx.xxx.xxx.xxx Status for the jail: postfix `- Banned IP list: xxx.xxx.xxx.xxx Status for the jail: pure-ftpd `- Banned IP list:xxx.xxx.xxx.xxx Status for the jail: sshd `- Banned IP list:xxx.xxx.xxx.xxx
Sólo tenemos que quitarla de esa lista con la instrucción:
fail2ban-client set pure-ftpd unbanip xxx.xxx.xxx.xxx
Si además, es un usuario que tiene IP estática y regularmente se va a conectar, podemos añadirlo a la lista blanca en el archivo /etc/fail2ban/jail.conf, poniendo la IP en el parámetro
ignoreip = xxx.xxx.xxx.xxx
Recientemente, mientras recuperábamos un volcado de una base de datos de un WordPress en otro servidor, tuvimos un contratiempo al encontrarnos con el siguiente error:
Error in query (1067): Invalid default value for ‘comment_date’
Eso nos ocurrió porque el servidor de destino, al ser un servidor de pruebas, tenía una versión ligeramente inferior de MySQL que la que tenía el servidor donde estaba alojado el site de WordPress. Al ser un servidor de pruebas, la solución más rápida y fácil fue modificar en el archivo my.cnf la configuración de MySQL añadiendo la línea
sql_mode=NO_ENGINE_SUBSTITUTION
Si el servidor hubiera sido en producción, la mejor solución entonces hubiera sido actualizar MySQL.
Nuestra compañera Silvia Suria ha publicado recientemente un libro sobre comercio electrónico en formato Kindle, titulado Errores comunes en la creación de un comercio electrónico. El enlace de la obra es éste: Ir a Amazon Kindle
En ella explica los problemas recurrentes que normalmente cometen los emprendedores o/y las empresas que deciden abrir una tienda online, y cómo evitarlos, por lo que es una obra recomendada para un amplio abanico de lectores, desde los entusiastas fundadores de una startup, a los directores de departamento que deciden entrar en el mundo digital de las ventas online de empresas más o menos consolidadas en el mercado tradicional.
El error «Unable to serialize value» viene generado por una codificación errónea del archivo CSV para las traducciones. Para los que trabajan con Windows, recordaros que hay que codificar siempre en UTF-8.
Para comprobarlo, hay que ejecutar en la línea de comandosphp -dmemory_limit=5G bin/magento setup:static-content:deploy de_DE --jobs=0 -f
En Magento 1.x el error en el login puede venir por problemas de caché en navegador o por problemas en versiones antiguas de código. Si no es vuestro caso y ya lo habéis chequeado todo, probad a ampliar la RAM de vuestro servidor, seguro que os funciona de nuevo. Y es que la falta de recursos no siempre viene dado por una lentitud en la página.
En Magento 2.x el error de login puede venir dado por problemas con la caché (podéis limpiarla vía línea de comandos o borrando el directorio var/cache), por falta de recursos como en la versión 1.x, o porque has activado la destrucción de datos de sesión al regenerar los ids de sesión. Desactiva esto último y funcionará todo.
En ambos casos, también puede ocurrir que haya alguna extensión instalada recientemente que esté dando problemas. Sería cuestión de desactivarla, limpiar caché y volver a intentarlo, siempre con una ventana de incógnito del navegador para mayor seguridad.
A veces al migrar una base de datos de Moodle nos hemos encontrado con el error siguiente:
Error: “#1071 – Specified key was too long; max key length is 767 bytes”
La solución más sencilla es ejecutar estas 3 instrucciones en la base de datos de destino antes de lanzar el archivo con el dump de la base de datos que corregirán el error.
use base_datos_destino;
set global innodb_large_prefix=on;
set global innodb_file_format=Barracuda;
set global innodb_file_per_table=true;
Si has hecho todo lo que te recomiendan las webs sobre limpieza de WeKnow.ac y sigues teniendo esa molesta redirección en tu Google Chrome, la solución más sencilla pasa por desinstalar Google Chrome con la herramienta para Mac «Clean My Mac» (sólamente con desinstalar el navegador arrastrándolo a la papelera de reciclaje no sirve), reiniciar tu equipo y volver a instalar el navegador de nuevo. Si tienes un usuario en Chrome para guardar tus preferencias y contraseñas, no perderás nada y la fastidiosa redirección por fín se borrará.
Y un truco para no volver a tener esa redirección es vigilar lo que instalamos y aceptamos al descargar aplicaciones y extensiones para el navegador. Un sistema Mac puede ser más seguro que un sistema Windows, pero parte de esa seguridad somos nosotros mismos. Debemos leer atentamente antes de instalar nada.
Aunque normalmente seguimos las guías de howtoforge.com, para que un servidor Web (LAMP) funcione correctamente debe tener instalados y configurados como mínimo los siguientes elementos:
Módulos:
- mod_expires
- mod_cached
- mod_deflate
- mod_headers
- mod_mem_cache
- mod_disk_cache
- mod_pagespeed
Cachés:
- OPcache
- Memcache
- Redis
Además de instalar todo esto, recomendamos configurar el módulo de PageSpeed para que utilice Memcache. Esto se consigue poniendo esta línea en el archivo de configuración del módulo de PageSpeed:
ModPagespeedMemcachedServers localhost:11211
Por supuesto, estamos hablando de servidores Web con Apache 2.4, HTTP2, PHP 7.x, etc
En esta ocasión os vamos a explicar qué hay que hacer cuando en la instalación de un Moodle 3.x con motor de base de datos MariaDB, llegamos al punto en el que chequea si el sistema coumple los requisitos mínimos y nos muestra estos errores:
| Información | Informe | Plugin | Estado |
|---|---|---|---|
| mysql_full_unicode_support#File_format |
Su base de datos tiene tablas que están usando Antelope como sistema de ficheros. Para un soporte completo de UTF-8 en MySQL y MariaDB requiere Barracuda como sistema de ficheros. Por favor convierta las tablas al sistema de ficheros Barracuda. Mire la documentación Administración vía línea de comandos para ver los detalles de alguna herramienta para convertir las tablas de InnoDB a Barracuda. |
Revisar | |
| mysql_full_unicode_support#Large_prefix |
Para el soporte completo de UTF-8 en MySQL y MariaDB se requiere cambiar la opción de MySQL ‘innodb_large_prefix’ a ‘ON’. Mira la documentación para más detalles. |
En este caso, la solución es bien sencilla: necesitaremos conectarnos a la base de datos (vía SSH o por PHPMyAdmin pero con usuario con plenos permisos en nuestra base de datos) y ejecutar estas 3 instrucciones dentro de la base de datos con la que vamos a trabajar:
SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=ON;
set global innodb_large_prefix = `ON`;
Después de esto, refrescamos la ventana de instalación de Moodle y la instalación nos dará el ok para poder seguir el proceso.
8 de junio de 2018.
Empiezo escribiendo este artículo con la fecha de hoy porque voy a explicar qué ha ocurrido con los dominios .es que los gestiona la entidad publica Red.es, del Ministerio de Energía, Turismo y Agenda Digital, y cómo podemos evitar en gran medida un desastre como el que han vivido hoy muchas webs y muchos usuarios con un correo con dominio .es. (Información sobre el incidente en este artículo)
¿Qué es lo que ha ocurrido? Sencillamente que la gestión de las zonas de dominios se les ha caído. Por ahora no se sabe mucho más de por qué ha sido, y las webs de red.es y dominios.es que serían las encargadas de informar, aún no muestran nada. Dominios.es a través de su Twitter ha informado escuetamente del problema:
Por otra parte, era de esperar, ya que la gestión de los dominios .es es mucho peor que la de un .info o un .com, por poner ejemplos.
Pero, ¿cómo podríamos evitar estos problemas, o por lo menos, paliarlos? Realmente hay muchas soluciones, por ejemplo, no depender sólo de un dominio .es únicamente. Personalmente suelo recomendar a un cliente cuando compra el dominio .es, que compre el homólogo .com y que redirija el .es al .com. Y que gestione el correo desde el dominio .com. ¿Por qué dar prioridad el .com? Pues porque la gestión de los .com recae sobre una organización más grande y fiable que la de .es. También está la idea de trabajar con varios dominios, y que el principal de todos ellos no sea un .es, sino un .net, .com, .info.
Pero aparte del problema que puede ocasionarnos el que una entidad de gestión de dominios se caiga o de problemas, podemos tener otros tipos de errores y contratiempos, por ejemplo, que nuestro servidor tenga que gestionar mucho contenido (archivos, imágenes) y servirlo internacionalmente. Entonces lo mejor es contar con un servicio CDN que sea el encargado de servir nuestros contenidos, descargando a los servidores web de ese trabajo.
Otro problema que podemos tener es un ataque de denegación de servicio por DNS. Si tenemos un problema como este, aparte de tener los servidores preparados para ello, y realizar las medidas consecuentes para paliarlo, nos vendría bien tener la web gestionado por distintos DNS, ya que el denegación de servicio se hace contra uno o varios servidores normalmente de la misma raíz de NS, por lo que si tenemos DNS en distintos países o distintos hostings, el ataque se verá disminuido.
Y estas son algunas de las reglas que solemos recomendar a los clientes para tener garantizado más del 90% de disponibilidad tanto de servicio web como de mail.