En un proyecto que se encuentra en producción se reportó la caída de la web, primero se procedió a hacer una consulta WHOIS, ya que ha pasado que puede haber vencido el dominio, se observó que todo estaba en orden.
Así que se procedió a entrar por SSH al servidor (en este caso un bitnami stack de AWS Lightsail) se comprobaron los servicios con el comando
sudo /opt/bitnami/ctlscript.sh status nos muestra los 3 servicios principales Apache, MySQL Y Php-fpm (esto puede cambiar dependiendo del stack, por ejemplo podría ser mysql o mariadb) si queremos solo el estado de uno solo deberemos tipear su nombre después de status por ej. sudo /opt/bitnami/ctlscript.sh status apache) estaban corriendo sin problemas aparentes, entonces se procedió a verificar el uso de los discos con el comando df -h el disco se encontraba al 100% de su capacidad imposibilitando la operación normal del servidor, luego desde la raíz del servidor ejecutamos el comando du -sh -- * | sort -rh que ordena los archivos y directorios por tamaño (de mayor a menor y nos muestra su tamaño y se determinó que la carpeta /opt/bitnami/mysql/data era la que tenía el mayor tamaño por lejos, para entrar a esta carpeta primero debemos ejecutar el comando sudo su y luego entrar a la ubicación (el comando nos cambia de usuario a root) dentro había numerosos archivos binlog (los archivos binlog son usados por MySQL para replicación y para algunas funciones de backup) de gran tamaño desde 1.7 gb hasta 1.1 gb, si queremos abrir estos archivos debemos usar el comando mysqlbinlog --no-defaults binlog.xxxx, se abrira en la terminal todo el archivo que dependiendo del tamaño puede tomar mucho tiempo en terminar de cargar.
Dentro podemos encontrar todas la sentencias que actualizan datos (CREATE, ALTER, INSERT, UPDATE, y DELETE), pero también contiene sentencias que podrían haber actualizado datos, como por ejemplo una sentencia DELETE que no encontró un match en la base de datos, estos archivos NO deben borrarse usando comandos UNIX se deben purgar desde MySQL, entrando en la base de datos, si en el proyecto se estuviera usando replicación deberían seguirse unos pasos previos y ser más cuidadoso, en nuestro caso podemos borrar los archivos binlog hasta la fecha que determinemos, con el comando PURGE BINARY LOGS BEFORE '2022-05-30 00:00:00'; esto borrara los archivos creados hasta la fecha indicada, podremos ver los archivos dentro de MySQL con el comando SHOW BINARY LOGS; o podemos verlos por el sistema de archivos, si queremos configurar la creación tamaño y tiempo que duran estos archivos lo podremos hacer en /opt/bitnami/mysql/my.cnf :
Para controlar cuánto tiempo deben durar en el sistema:
binlog_expire_logs_seconds=43200
12 horas como ejemplo.
Para controlar su tamaño en bytes:
max_binlog_size = 300000000
300 mb por ejemplo.
Pero si lo que queremos es desactivar la creación de estos archivos, lo que debemos hacer es primero para MySQL con el comando sudo /opt/bitnami/ctlscript.sh stop mysql despues agregar la siguiente línea en el mismo archivo (my.cnf)
disable_log_bin y luego iniciar el servicio sudo /opt/bitnami/ctlscript.sh start mysql
Adicionalmente también se observó tráfico inusual proveniente de ips de procedencia China, si nos dirigimos a la ubicación de los logs de Apache cd /opt/bitnami/apache2/logs/ y luego ejecutamos el comando tail -n 10000 access_log | awk '{print $1}'| sort| uniq -c| sort -nr| head -n 10 nos mostrara las 10 ips que han tenido más conexiones con el servidor y si queremos inspeccionar que visito cada ip lo podemos hacer con el comando grep "ATTACKER_IP" access_log y podremos ver si se a conectado a ubicaciones que existen o no y el tiempo en que se hacen estas conexiones si son varias en el mismo segundo etc. podremos determinar que es un bot, generalmente los bots eligen buscar vulnerabilidades o aprender las rutas del proyecto, se observó que en nuestro caso intentaban acceder a ubicaciones que claramente no existen, o a otras rutas de búsqueda con muchos parámetros, configurándose en un ataque DDoS (ataque de denegación de servicio) en la documentación de bitnami nos dice que identificando estas ips las podemos bloquear en el archivo /opt/bitnami/apps/APPNAME/conf/httpd-app.conf agregando la ip de la siguiente manera:
deny from 1.2.3.4
o para varias ip seria:
deny from 1.2.3.4
deny from 5.6.7.8
deny from 9.10.11.12
Luego chequeamos que la sintaxis sea correcta con el comando apachectl -t si todo está bien nos dará un mensaje de “Syntax OK” de lo contrario deberemos corregir el error, el error nos indicará en qué líneas está el problema.
Reiniciamos Apache para que los cambios surtan efecto sudo /opt/bitnami/ctlscript.sh restart apache
Bitnami no dice como tratar con los bots que realizan una gran cantidad de requests pero lo que pude observar es que hay muchas ip con pocas conexiones pero que buscan rutas de búsqueda con muchos parámetros y son muy numerosas más de 4000, para ver la ubicación geográfica de una ip, use una herramienta online https://ipgeolocation.io/ y asi pude corroborar que la mayoría sino todas las ips atacantes provienen de china. Hay algunas formas de filtrar/negar el acceso a todas las IP de un país con el .htaccess, el mismo archivo antes mencionado (httpd-app.conf ) o mediante un firewall, no obstante con el uso de una CDN podría minimizar los problemas con los bots al servirles después de su primera visita el sitio que tiene en su caché.
Me pareció interesante el artículo
Añadir nuevo comentario