LinuxParty

Las empresas de la industria aeronáutica auxiliar advierten del impacto laboral de los paros, mientras Airbus cierra sin acuerdo una de las mesas de negociación y alerta sobre las entregas civiles y militares

La huelga indefinida de Airbus España comienza a extender sus consecuencias más allá de las fábricas del fabricante aeronáutico. La reducción de actividad está afectando a empresas proveedoras y subcontratistas, algunas de las cuales estarían valorando finalizar contratos laborales si el conflicto continúa.

La información publicada inicialmente no identifica a las compañías afectadas, el número de empleos amenazados ni contratos comerciales formalmente cancelados con Airbus. Por tanto, no puede afirmarse que los proveedores hayan comenzado a romper sus acuerdos de suministro con el fabricante.

Lo conocido es que la industria auxiliar depende directamente del ritmo de producción de las plantas españolas. Cuando se paralizan líneas o disminuyen los trabajos encargados, las empresas externas reciben menos carga de trabajo y deben reorganizar turnos, plantillas y entregas.

Una huelga iniciada tras meses de desacuerdo

La actual huelga indefinida comenzó el 25 de agosto y fue convocada por UGT, CGT y la Unión de Trabajadores Independientes y Libres (ÚTIL).

El conflicto tiene su origen en las negociaciones sobre salarios, recuperación del poder adquisitivo, teletrabajo y otras condiciones laborales.

Durante julio, Airbus ya sufrió una primera fase de movilizaciones. Posteriormente, la empresa alcanzó un preacuerdo con CCOO, SIPA y ATP, organizaciones que representan una parte mayoritaria de la comisión negociadora.

Sin embargo, la plantilla rechazó ese documento en referéndum por un margen relativamente estrecho. El 49,15 % votó en contra, el 45,95 % lo respaldó y el 4,62 % se abstuvo, con una participación superior al 81 %.

Tras las vacaciones estivales, UGT, CGT y ÚTIL reanudaron las movilizaciones mediante una huelga indefinida.

Al encender un ordenador podemos utilizar determinadas teclas para entrar en la BIOS/UEFI o abrir directamente el menú de arranque.

Aunque suelen confundirse, realizan funciones diferentes:

• BIOS o UEFI: permite modificar la configuración del equipo, activar la virtualización, cambiar el orden de arranque, habilitar Secure Boot o consultar los componentes detectados.
• Menú de arranque o Boot Menu: permite elegir temporalmente desde qué dispositivo iniciar, como un disco duro, una memoria USB o un DVD, sin cambiar permanentemente la configuración.

Teclas según el fabricante

La tecla Supr también puede aparecer identificada como Del o Delete, dependiendo del teclado.

El incendio declarado estos días en las inmediaciones de Cañaveral (Cáceres) ha obligado a evacuar preventivamente a los vecinos de Casas de Millán y Grimaldo, movilizando un amplio dispositivo de emergencia compuesto por INFOEX, Guardia Civil, UME, Protección Civil, Cruz Roja y numerosos medios terrestres y aéreos.

Afortunadamente, gracias al enorme trabajo de todos ellos y a unas condiciones meteorológicas más favorables, el incendio pudo estabilizarse progresivamente, permitiendo el regreso de los vecinos a sus hogares.

Sin embargo, una vez que el humo desaparezca y las cámaras de televisión abandonen la zona, quedará una pregunta que deberíamos hacernos todos:

¿Estamos haciendo todo lo posible para evitar que estos incendios lleguen a producirse?

Porque apagar incendios es imprescindible.

Pero evitar que ocurran debería ser todavía más importante.

Todo comenzó con un accidente...

Según las primeras informaciones, el origen del incendio estuvo relacionado con un camión que comenzó a arder en las proximidades de la autovía.

Puede parecer sorprendente.

Un único vehículo.

Una sola chispa.

Y, pocas horas después, cientos de personas abandonando sus viviendas por precaución.

La pregunta no es únicamente cómo comenzó el incendio.

La verdadera pregunta es por qué pudo propagarse con tanta rapidez.

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
}