☰

¿Cómo rastrear registros específicos en Ubuntu? (UPC)

tag-icon • tag-icon apache-2.2 amazon-web-services security amazon-ec2 hacking
¿Cómo rastrear registros específicos en Ubuntu? (UPC)

Tenemos esta instancia EC2: T2.medium, ejecutando apache, con 4 hosts virtuales (4 sitios). A veces, de la nada, la CPU alcanza niveles muy altos, tal vez un ataque.

He visto que algunos de nuestros archivos de WordPress han sido modificados.

¿Cómo puedo comprobar quién ha estado escribiendo en esos archivos? ¿Cómo podría verificar los registros de la CPU para ver qué proceso la ha estado afectando? ¿Existe alguna métrica de Cloudwatch que pueda utilizar?

Hemos estado fortaleciendo el servidor: actualizaciones, ejecutando AWS Inspector, Lynis, modificando el archivo de configuración ssh.

¿Hay alguna forma de ver quién y cómo lograron ingresar y modificar esos archivos de WordPress?

¿Y qué otras prácticas de endurecimiento recomiendas?

Respuesta1

Hay varias preguntas aquí.

¿Quién ha estado escribiendo en los archivos?

El sistema operativo no registra esta información, pero hay algunas pistas:

  • la fecha de modificacion
  • Los permisos de archivos

Utilice la fecha de modificación de los archivos para limitar la búsqueda de sus registros de acceso a Apache. Verifique al menos si hay POSTsolicitudes e inicios de sesión de esa época. Por ejemplo, esto mostraría todos los intentos de inicio de sesión:

zgrep 'POST /wp-login.php' /var/log/apache2/*access*

Luego puede filtrar la salida por el rango de tiempo que obtuvo del momento de modificación de los archivos.

Si solo determinados usuarios del sistema pueden escribir en los archivos que se han modificado, entonces puede estar razonablemente seguro de que fueron modificados por esos usuarios del sistema.

¿Qué procesos están vinculando la CPU?

Esta información no se registra de forma predeterminada. Si no es práctico intentar monitorear el servidor "en vivo", por ejemplo con top, existen varias herramientas de registro que puede utilizar.Aquí hay una pregunta sobre el error del servidor.donde se recomiendan diversas herramientas para este fin.

Determinar si has sido hackeado

Este es un tema más amplio, pero el lugar donde comenzaría, ya que mencionaste modificaciones a los archivos de WordPress, es determinar si estas modificaciones son maliciosas. Ejecute un escáner de malware de WordPress y/o busque patrones maliciosos como eval(base64_decode(, php web shells, etc. Si no está seguro, sea persistente, minucioso y publique más preguntas si es necesario.

Determinar cómo obtuvo acceso un atacante

Si está razonablemente seguro de que el sitio o los sitios fueron pirateados, puede intentar determinar cómo obtuvo acceso el atacante. Las dos formas más probables en que esto podría haber sucedido son iniciando sesión en una cuenta de usuario administrador o mediante una vulnerabilidad. En la mayoría de los casos, es difícil determinarlo con un alto grado de certeza. Pero si ha estado ejecutando software con una vulnerabilidad conocida, especialmente uno con un exploit público y que permite la ejecución remota de código, entonces esta es una posibilidad muy probable. Y si un usuario administrador de WordPress tiene credenciales débiles, o sus credencialesse filtraron, entonces esta es una posibilidad muy probable.

Endurecimiento adicional

Si cree que el servidor ha sido comprometido, debe consultarla respuesta canónica sobre el tema.

Respuesta2

Esto no pretende ser una respuesta completa, es complementaria a la respuesta de sceox.

deberías mirarendurecimiento de Wordpress, yPermisos de archivos de Wordpress.

Tengo las cosas configuradas así:

  • Un usuario/grupo posee los archivos
  • PHP es parte de un grupo que puede leer los archivos de Wordpress, incluidos complementos/temas/etc, pero no puede escribir en ellos. Puede escribir en la carpeta de cargas para que las imágenes se puedan cargar usando la GUI de Wordpress. Esto hace que sea muy difícil que cualquier cosa en Internet comprometa los archivos de Wordpress.
  • Tengo un script que usa elCLI de WordPresspara hacer actualizaciones de Wordpress y los complementos a las 2 am.
  • Cualquier complemento nuevo debe instalarse con Wordpress CLI. No es tan conveniente, pero es MUCHO más seguro.

Aquí está el script que uso, que se ejecuta en un trabajo cron

#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

echo
echo Wordpress Update and Permissions Script Starting
echo "$(date) Wordpress update and backup started"   >> /var/log/me/my-wordpress-upgrades 2>&1

# Function to upgrade wordpress
function upgrade_wordpress() {
    # set up folders in the formats needed
    dir=$1
    uploads=$1/wp-content/uploads

    echo Upgrading Wordpress core, plugins, themes in ${dir}
    sudo -H -u www-user bash -c "wp core update --path=$dir"
    sudo -H -u www-user bash -c "wp plugin update --all --path=$dir"
    sudo -H -u www-user bash -c "wp theme update --all --path=$dir"

    echo Setting wordpress permissions to 755 files and 644 folders
    find ${dir} -type d -exec chmod 755 {} \;
    find ${dir} -type f -exec chmod 644 {} \;
    chmod 440 ${dir}/wp-config.php

    echo Making uploads folder ${uploads} writable by the web server
    chown -R www-data:www-data ${uploads}

    echo Wordpress upgrade for $1 complete
    echo
    echo
}


echo Setting /var/www permissions to www-user:www-data
chown -R www-user:www-data /var/www/

# Run Wordpress update for each wordpress install
upgrade_wordpress /var/www/blog1
upgrade_wordpress /var/www/blog2

información relacionada