LinuxParty

En uno de nuestros servidores Linux administrados, comenzamos a observar un comportamiento bastante extraño: el firewall funcionaba correctamente, pero, sin motivo aparente, todas sus reglas desaparecían.

Al ejecutar:

iptables -L -n

encontrábamos las cadenas vacías y las políticas predeterminadas en ACCEPT. Es decir, el servidor continuaba funcionando, pero había perdido todas las reglas de bloqueo que debían protegerlo.

Lo más desconcertante era que, después de restaurar el firewall, las reglas volvían a desaparecer pocos minutos después.

En este artículo explicamos la investigación que realizamos, las pistas que encontramos y cómo descubrimos que APF estaba ejecutando periódicamente un flush de todas las reglas de iptables.

Un script de vigilancia detectó la caída

El servidor contaba con un script propio que se ejecutaba periódicamente desde cron. Su función era comprobar el estado de diferentes servicios esenciales:

cat /root/bin/Comprueba.sh

Su contenido era similar al siguiente:

#!/bin/bash
#
# Comprueba que una serie de servicios
#

echo "Comprobando 1 de 10"
/root/bin/compruebasshd.sh

echo "Comprobando 2 de 10"
/root/bin/compruebafirewall.sh

echo "Comprobando 3 de 10"
/root/bin/compruebanamed.sh

echo "Comprobando 4 de 10"
/root/bin/compruebanamed-old.sh

echo "Comprobando 5 de 10"
/root/bin/compruebapostfix.sh

echo "Comprobando 6 de 10"
/root/bin/compruebadovecot.sh

echo "Comprobando 7 de 10"
/root/bin/compruebaccesosfallidos.sh

if [ ! -f /root/cargatrabajo.tmp ]; then
    echo "Comprobando 8 de 10"
    /root/bin/compruebahttpd.sh

    echo "Comprobando 9 de 10"
    /root/bin/compruebanginx.sh

    echo "Comprobando 10 de 10"
    /root/bin/compruebamysqld.sh
fi

if [ -f /root/cargatrabajo.tmp ]; then
    source /root/cargatrabajo.tmp

    quedan=$(echo "$quedan - 1" | bc)

    echo "Quedan: $quedan - $(date) -> $A" >> "$REGISTROSLOGS"
    echo "quedan=$quedan" > /root/cargatrabajo.tmp

    if [ "$quedan" -le 0 ]; then
        rm -f /root/cargatrabajo.tmp
        /root/bin/cargatrabajo.sh
    else
        exit 0
    fi
fi

Entre esas comprobaciones se encontraba:

/root/bin/compruebafirewall.sh

Auditor Web es un script Bash de auditoría de seguridad pensado para servidores Linux que alojan páginas desarrolladas en PHP. Permite buscar archivos sospechosos, código ofuscado, funciones peligrosas, modificaciones recientes, permisos inseguros y otros indicios habituales de una intrusión.

El script reconoce instalaciones de Joomla y WordPress, aunque también puede trabajar con cualquier sitio PHP en modo genérico. Está especialmente indicado para servidores administrados mediante Plesk, servidores de hosting compartido, VPS y máquinas dedicadas.

Una de sus características más útiles es que no se limita a generar un informe: después de cada análisis crea automáticamente un segundo script, específico para esa auditoría, con el que se pueden abrir uno por uno los archivos sospechosos utilizando bat, batcat o less.

De este modo resulta mucho más sencillo revisar el código encontrado, identificar una posible puerta trasera y distinguirla de una coincidencia legítima.

Importante: Auditor Web es una herramienta de detección y revisión. Una coincidencia no demuestra por sí sola que un archivo contenga malware.

¿Qué analiza Auditor Web?

El script realiza, entre otras, las siguientes comprobaciones:

• Archivos PHP modificados recientemente.
• Extensiones dobles y nombres frecuentemente utilizados por webshells.
• Ficheros PHP dentro de images, media, uploads, tmp, cache o directorios similares.
• Funciones capaces de ejecutar comandos del sistema.
• Código ofuscado mediante Base64, eval(), gzinflate() y técnicas parecidas.
• Líneas de código anormalmente largas.
• JavaScript inyectado u ofuscado.
• Descargas remotas, sockets y escritura de archivos.
• Archivos y directorios con permisos 777.
• Elementos escribibles por cualquier usuario.
• Enlaces simbólicos que salen de la raíz auditada.
• Reglas sospechosas en .htaccess, .user.ini y php.ini.
• Peticiones relacionadas con webshells en los registros de Apache o Nginx.
• Tareas programadas que utilizan curl, wget, PHP, Python o directorios temporales.
• Versiones locales de Joomla, WordPress, plugins, plantillas y extensiones.
• Usuarios administradores y determinados contenidos sospechosos almacenados en la base de datos.

El análisis del sistema de archivos se realiza en modo de solo lectura. El script no elimina ni pone en cuarentena ningún archivo automáticamente.

#!/usr/bin/env bash
#
# auditor-web-malware.sh
# Auditor de solo lectura para buscar indicios de compromiso en sitios PHP.
# Detecta Joomla, WordPress o funciona en modo generico.
# Inspirado en la guia de LinuxParty sobre Helix Ultimate y SP Page Builder.
#
# No elimina, mueve ni modifica archivos o registros de la base de datos.

set -uo pipefail
export LC_ALL=C

VERSION="1.3.1"
DAYS=30
SINCE=""
ROOT=""
LOG_DIR=""
TOKEN=""
OUTPUT=""
MAX_RESULTS=200
SKIP_DB=0
QUIET=0
COLOR_MODE="auto"
WEB_USERS="apache,www-data,nginx"
CMS_MODE="auto"
CMS="generic"
ALERT_HITS=0
REVIEW_HITS=0
ERRORS=0
MYSQL_CNF=""
SUSPECTS_OUTPUT=""
REVIEW_SCRIPT=""
RUN_STAMP=$(date '+%Y%m%d-%H%M%S')

usage() {
    cat <<'EOF'
Uso:
  sudo ./auditor-web-malware.sh --root /ruta/al/sitio [opciones]

Opciones:
  -r, --root DIR       Directorio raiz del sitio web (obligatorio).
  -d, --days N         PHP modificados en los ultimos N dias (30).
      --since FECHA    Buscar ficheros posteriores a FECHA; ej. 2026-07-15.
  -l, --logs DIR       Directorio de logs Apache/Nginx. Se intenta detectar.
  -t, --token TEXTO    Token, nombre de webshell o texto literal para los logs.
  -o, --output FILE    Informe de salida. Por defecto, en el directorio actual.
  -m, --max N          Maximo de lineas mostradas por prueba (200).
      --web-users LIST Usuarios web separados por coma (apache,www-data,nginx).
      --cms TIPO       auto, joomla, wordpress o generic (auto).
      --skip-db        No analizar la base de datos del CMS.
  -q, --quiet          No mostrar progreso; escribir solamente el informe.
      --color MODO     Colores: auto, always o never (auto).
      --no-color       Equivale a --color never.
  -h, --help           Mostrar esta ayuda.
      --version        Mostrar la version.

Codigos de salida:
  0  Auditoria terminada sin indicios de alta prioridad.
  1  Se encontraron indicios de alta prioridad que deben revisarse.
  2  Error de uso o no se pudo completar una parte esencial.

Ejemplos:
  sudo ./auditor-web-malware.sh -r /var/www/vhosts/dominio/httpdocs
  sudo ./auditor-web-malware.sh -r /var/www/vhosts/dominio/httpdocs \
       --since 2026-07-15 --logs /var/www/vhosts/system/dominio/logs
  sudo CMS_DB_PASSWORD='clave' ./auditor-web-malware.sh -r /srv/wordpress

La variable CMS_DB_PASSWORD, si existe, sustituye la clave leida de
configuration.php o wp-config.php. La clave nunca se imprime en el informe.

El auditor genera junto al informe:
  - Una lista terminada en .sospechosos.txt.
  - Un script autonomo revisar-SITIO-FECHA.sh para examinar con bat o less
    los ficheros sospechosos de esa ejecucion concreta.
EOF
}

La Comisión Europea continúa impulsando nuevas medidas para reforzar la protección de los menores en Internet. Entre ellas se encuentra la implantación de sistemas de verificación de edad que permitan impedir el acceso de menores a determinados contenidos y redes sociales.

Sobre el papel, el objetivo parece difícil de cuestionar. Todos coincidimos en que los menores deben estar protegidos frente a contenidos inapropiados, estafas, manipulación o plataformas diseñadas para captar su atención durante horas.

Sin embargo, cuando la protección de los menores se convierte en la puerta de entrada a sistemas de verificación de identidad obligatorios, conviene preguntarse hasta dónde estamos dispuestos a ceder privacidad a cambio de seguridad.

La historia se repite

No es la primera vez que una medida nace con una finalidad legítima.

Las cámaras de vigilancia se instalaron para prevenir delitos.

La conservación de determinados datos de comunicaciones se justificó por la lucha contra el terrorismo.

Los sistemas biométricos comenzaron utilizándose para mejorar la seguridad en aeropuertos y fronteras.

En todos los casos existía un objetivo razonable.

La cuestión no suele ser el propósito inicial, sino hasta dónde puede extenderse una vez que la infraestructura ya existe.

Porque una vez creado un sistema capaz de verificar la identidad de millones de ciudadanos, la tentación de utilizarlo para nuevos fines siempre estará presente.

Hoy puede servir para impedir que un menor acceda a una red social.

¿Y mañana?

La privacidad es un derecho, no un obstáculo

Desde hace años, la Unión Europea ha sido uno de los mayores defensores de la privacidad digital. El Reglamento General de Protección de Datos (RGPD) marcó un antes y un después en la protección de la información personal.

Precisamente por eso resulta paradójico que ahora el debate se centre en cómo identificar cada vez a más ciudadanos para acceder a determinados servicios digitales.

Aunque las instituciones europeas aseguran que estos sistemas incorporarán garantías técnicas y minimizarán la cantidad de datos compartidos, sigue habiendo preguntas importantes que merecen respuesta.

¿Quién custodiará esa información?

¿Durante cuánto tiempo?

¿Qué organismos podrán acceder a ella?

¿Qué ocurrirá si en el futuro cambian las normas o las prioridades políticas?

Cuando hablamos de identidad digital, las preguntas son tan importantes como las respuestas.

"Qué se puede hacer hoy con n8n e IA, y qué todavía está en fase experimental."

Durante las tres primeras entregas de esta serie hemos aprendido qué es n8n, cómo instalarlo y cómo construir automatizaciones útiles para administrar servidores Linux. Pero el ecosistema tecnológico está cambiando rápidamente. La irrupción de los grandes modelos de lenguaje (LLM) y de los llamados agentes inteligentes está transformando la forma en que interactuamos con las aplicaciones. ¿Qué ocurre cuando unimos n8n con la Inteligencia Artificial? La respuesta abre un escenario completamente nuevo para administradores de sistemas, desarrolladores y empresas.

La automatización entra en una nueva etapa

Hasta hace muy poco, automatizar significaba ejecutar una serie de pasos predefinidos.

Si ocurría A...

Entonces ejecutar B.

Después C.

Y finalmente D.

Ese modelo sigue siendo válido.

Pero la Inteligencia Artificial añade una capacidad completamente nueva: tomar decisiones basadas en el contenido de la información, no únicamente en reglas fijas.

Ya no se trata solo de mover datos entre aplicaciones.

Ahora podemos analizarlos, resumirlos, clasificarlos e incluso generar respuestas automáticamente.

¿Qué aporta realmente un LLM?

Un modelo de lenguaje como GPT, Llama, Mistral o Gemma no sustituye a n8n.

Lo complementa.

n8n sigue siendo quien orquesta el proceso.

La IA simplemente actúa como un nodo más dentro del Workflow.

Por ejemplo:

Correo recibido
        │
        ▼
Extraer contenido
        │
        ▼
Modelo de IA
        │
        ▼
Clasificar incidencia
        │
        ▼
Crear ticket
        │
        ▼
Enviar respuesta

Sin escribir reglas para cada caso.

Es el propio modelo quien interpreta el contenido.

Durante los últimos días se ha confirmado una campaña de ataques contra sitios Joomla 3 que utilizan Helix Ultimate, Helix 3 y SP Page Builder. Los atacantes están aprovechando varias vulnerabilidades ya corregidas para modificar la configuración del sitio, inyectar código JavaScript y, en algunos casos, crear nuevos usuarios con privilegios de Super Administrador. (JoomShaper)

En ExtreHost hemos podido analizar un caso real en producción donde el código malicioso había sido almacenado dentro del campo

params

de un elemento del menú principal.

A continuación explicamos cómo comprobar si tu instalación ha sido afectada y qué pasos recomendamos seguir para eliminar la infección.

¿Qué vulnerabilidades corrigen las actualizaciones?

JoomShaper ha publicado actualizaciones de seguridad para Joomla 3 que corrigen, entre otros problemas:

• Vulnerabilidades XSS (Cross Site Scripting) en Mega Menu, galerías y Media Manager.
• Falta de validación CSRF en llamadas AJAX.
• Comprobaciones insuficientes de permisos.
• Validación incorrecta de rutas.
• Subidas inseguras de archivos.
• Redirecciones abiertas (Open Redirect).

Estas vulnerabilidades permiten que un atacante modifique configuraciones del sitio o inserte código JavaScript que posteriormente se ejecutará cuando un administrador acceda al panel de Joomla. (JoomShaper)

Lo primero: actualizar inmediatamente

Antes de limpiar el sitio es imprescindible instalar las versiones corregidas.

Descargas oficiales:

• Helix Ultimate Security Update
• Artículo oficial de JoomShaper sobre las vulnerabilidades

Si utilizas:

• Helix Ultimate
• Helix3
• SP Page Builder

deben actualizarse todos.

Actualizar únicamente SP Page Builder no elimina una posible explotación realizada mediante Helix Ultimate.

En las dos primeras partes de esta serie aprendimos qué es n8n, cómo instalarlo y cómo construir nuestros primeros Workflows. Ha llegado el momento de utilizarlo en situaciones reales. En este artículo veremos cómo convertir n8n en un auténtico centro de operaciones para administrar servidores Linux, automatizar copias de seguridad e integrar aplicaciones como Dolibarr, WordPress, Nextcloud o Proxmox mediante sus APIs.

Ya no hablamos de pruebas

Hasta ahora todos los ejemplos tenían un objetivo didáctico.

Aprender nodos.

Comprender cómo funcionan los Triggers.

Familiarizarnos con la interfaz.

Sin embargo, el verdadero potencial de n8n aparece cuando comenzamos a utilizarlo para resolver tareas que realizamos todos los días.

Muchos administradores Linux mantienen decenas de pequeños scripts Bash repartidos por distintos servidores.

Otros dependen exclusivamente de cron.

Algunos incluso conservan hojas de cálculo donde anotan tareas de mantenimiento.

n8n permite centralizar buena parte de ese trabajo en una única plataforma visual, facilitando la reutilización, la monitorización y el mantenimiento de las automatizaciones.

No pretende sustituir a Bash.

Al contrario.

Lo complementa.

Podemos seguir utilizando nuestros scripts de siempre y dejar que sea n8n quien los ejecute, controle el resultado y actúe en consecuencia.

Caso práctico 1

Automatizar una copia de seguridad completa

Una de las tareas más repetitivas de cualquier administrador consiste en verificar que las copias de seguridad se ejecutan correctamente.

Imaginemos que ya disponemos de un script Bash llamado:

/usr/local/bin/backup.sh

Nuestro objetivo será:

• ejecutarlo cada noche;
• comprobar si ha finalizado correctamente;
• registrar el resultado;
• enviar una notificación.

El Workflow podría representarse así:

Schedule Trigger
        │
        ▼
SSH
        │
        ▼
backup.sh
        │
        ▼
IF
   ┌───────────────┐
   ▼               ▼
Éxito           Error
   │               │
Email        Telegram

En este caso n8n no sustituye al script.

Simplemente lo orquesta.

Una ventaja importante es que podremos consultar el historial completo de ejecuciones desde la propia interfaz, sin necesidad de revisar manualmente los registros del sistema.

Además, el nodo SSH permite ejecutar comandos remotos sobre uno o varios servidores, por lo que un único Workflow puede coordinar copias de seguridad distribuidas. (n8n)