Todos los que tenemos algún wordpress y revisamos los logs periódicamente vemos que continuamente hay accesos por POST al xmlrpc.php. Algunas veces son ataques y otras son simples consultas de bots. En cualquier caso son accesos que no me valen para nada y generan tráfico innecesario.

Hace poco revisando unos logs vi miles de accesos por POST desde una ip de Ucrania y con el user agent de GoogleBot. No se que quería pero seguro que nada bueno. 🙂

Lo que recomiendan en muchos sitios de borrar ese fichero a mi no me convence por que si actualizas el wordpress lo vuelves a tener ahí y hay veces que se hace un uso legítimo de ese fichero para, p.e. publicar post desde programas externos.

Una característica habitual de los bots es que hacen las peticiones por HTTP/1.0 en vez del habitual HTTP/1.1 así que aprovechando esta característica he preparado este pequeño código que bloquea las peticiones por POST y HTTP1.0 al xmlrpc.php. Obviamente si el bot trabaja con HTTP/1.1 esto no funcionará.

Lo más interesante de este código es que para evitar ifs anidados concateno dos valores en una variable. Si se cumple la primera condición el valor de la variable es “bot” y si se cumple la segunda añado a lo que tenga la variable el valor “post”, de esa forma sólo devuelve 403 si las dos variables cumplen la condición. Este método permite construir tantos ifs anidados como quieras, simplemente hay que añadir más valores a la cadena.

## Block xmlrpc.php POST http1.0
  location ^~ /xmlrpc.php {
    set $mata_bot 0;
    if ($server_protocol ~* "HTTP/1.0") {
        set $mata_bot "bot";
        }
    if ($request_method = POST ) {
        set $mata_bot "${mata_bot}-post";
        }
    if ($mata_bot = "bot-post"){
       return 403;
       }
   }

Espero que le sea útil a alguien más.

Información sobre ataques de fuerza bruta con xmlrpc.php

Este scrip en bash permite cambiar todas las claves de akismet de los blogs de un servidor. Simplemente busca todos los wp-config.php, saca los datos de acceso al mysql, comprueba si la clave que tienen metida es diferente de la nueva y si es así la cambia. Funciona perfectamente con wordpress multisite.

Acordaros de cambiar la clave y la ruta por la de vuestros servidores.

#!/bin/bash
 
CLAVE_AKISMET='mi_clave_akismet'
RUTA_WEB='/var/www/html/'
 
for WPCONFIG in $(find $RUTA_WEB -type f -name "wp-config.php")
        do
                DBNAME=$(grep "DB_NAME" $WPCONFIG | awk '{split($0,a,","); print a[2]}' | awk '{split($0,a,";"); print a[1]}' | sed -e 's/)//g' | sed -e "s/'//g" | tr -d " ")
                DBUSER=$(grep "DB_USER" $WPCONFIG | awk '{split($0,a,","); print a[2]}' | awk '{split($0,a,";"); print a[1]}' | sed -e 's/)//g' | sed -e "s/'//g" | tr -d " ")
                DBPASS=$(grep "DB_PASSWORD" $WPCONFIG | awk '{split($0,a,","); print a[2]}' | awk '{split($0,a,";"); print a[1]}' | sed -e 's/)//g' | sed -e "s/'//g" | tr -d " ")
                DBHOST=$(grep "DB_HOST" $WPCONFIG | awk '{split($0,a,","); print a[2]}' | awk '{split($0,a,";"); print a[1]}' | sed -e 's/)//g' | sed -e "s/'//g" | tr -d " ")
 
 
                if [ $(mysql -u $DBUSER -p$DBPASS -h $DBHOST $DBNAME -Ns -e "show tables;" | grep -c _options) -gt 0 ];
                then
 
                        for TABLA_OPTIONS in $(mysql -u $DBUSER -p$DBPASS  -h $DBHOST $DBNAME -Ns -e "show tables;" | grep "_options")
                        do
                                clave=$(echo "select option_value from "$TABLA_OPTIONS" where option_name='wordpress_api_key';" | mysql -u $DBUSER -p$DBPASS  -h $DBHOST $DBNAME -Ns)
                                if [ "$clave" != "$CLAVE_AKISMET" ];
                                then
                                        echo "Actualizando TABLA_OPTIONS:" $TABLA_OPTIONS
                                        echo "update "$TABLA_OPTIONS" set option_value='"$CLAVE_AKISMET"' where option_name='wordpress_api_key';" | mysql -u $DBUSER -p$DBPASS -h $DBHOST $DBNAME  -Ns
                                fi;
                        done
                fi;
        done

A veces es interesante acceder a algún servidor por ssh sin tener que introducir las claves. La forma más sencilla de hacerlo es:
1.- Comprueba si tienes ya creadas tu par de claves. Vete a /home/tu_usuario/.ssh/ y comprueba si existen los ficheros id_rsa y id_rsa.pub . Si no existen genéralos con

ssh-keygen

2.- Una vez que ya tienes tu par de claves copialas al host destino con

ssh-copy-id usuario@host_destino

Ahora ya podrás conectarte directamente a ese host sin necesidad de introducir la clave. Ten en cuenta que si hay un problema de seguridad en tu equipo estarás comprometiendo todos los equipos a los que te puedes conectar sin clave, úsalo con mucho cuidado.

Desde este año es obligatorio que todos los trámites que se realicen con el registro mercantil se hagan telemáticamente. Por mi parte todo perfecto por que así nos ahorramos tiempo y viajes pero como siempre que hay que realizar algún trámite online con la administración llegaron los problemas.

Hoy me ha llegado una notificación y al intentar visualizarla me daba el siguiente error: “Error obteniendo certificados de usuario.
Se ha producido un error que impide el correcto funcionamiento de la aplicación
Por favor disculpen las molestias.
Póngase en contacto con nuestro Servicio técnico en el tfno: 902 201 200 / 91 270 17 97.”

registradores2

 

y después “Error obteniendo certificados de usuario

registradores3

 

Por supuesto que tanto los certificados como java están funcionando correctamente.

Aunque ya me imaginaba la respuesta he llamado al teléfono de referencia y la respuesta ha sido la típica: “Abra una nueva ventana del Internet Explorer” y cuando le he explicado que no tengo internet explorer ni windows ni nada de eso me ha contestado lo habitual “es que sólo funciona con internet explorer”. La verdad es que a estas alturas de la película que alguien desarrolle sólo para internet explorer es de tontos, ya se que no me van a hacer ni caso y que por muchas reclamaciones que presente no van a solucionar nada pero me fastidia que me respondan eso, así que el chaval que me respondió al teléfono me ha tenido que escuchar un ratito despotricar sobre todo este tema.

Revolviendo un poco me he dado cuenta de que si cambias un pequeño parámetro de la url ya puedes acceder al documento sin problemas, concrétamente el parámetro es tipoDetalle y hay que cambiar el valor de 2 a 3, así:

URL original (el código de petición lo he eliminado)
https://www.registradores.org/presentacionTelem/notifComuAvisoDocs.do?dispatch=mostrarDatosDetalle&pantalla=basicPage&tipoDetalle=2&codPeticionEnvioEDoc=xxxxxxxx

Se cambia a este:
https://www.registradores.org/presentacionTelem/notifComuAvisoDocs.do?dispatch=mostrarDatosDetalle&pantalla=basicPage&tipoDetalle=3&codPeticionEnvioEDoc=xxxxxxxx

Y esta es la pantalla final donde ya puedo acceder al documento.

registradores4

Ahora que lo tengo aquí publicado a ver si no se me olvida para la próxima vez. 🙂