Ya sea usando un plugin o mediante código.

¿Por qué bloquear por país?

Una de las razones más importantes para bloquear países es para evitar ataques de bots.

Los bots intentan abusar de vulnerabilidades. Buscan por software que no ha sido actualizado. Buscan de cualquier agujero que exista para poder tomar control de un sitio web. Por lo cual bloquear ciertos países puede ayudar a mejorar la seguridad.

Pero a la vez, también se puede bloquear por país debido a cuestiones legales. O simplemente por que no queremos que nadie de dicho país pueda acceder a ciertos recursos, como la zona de administración de WordPress.

Todas estas son razones válidas. Pero, ¿cómo lo podemos lograr?

1. Mediante un plugin

Una de las formas mas sencillas de bloquear por país en WordPress es usando una solución ya desarrollada como un plugin.

Existen multiples soluciones como iQ Block Country o IP2Location Country Blocker. En ambos casos, usan bases de datos que provienen de servicios y que hay que descargar.

Con ambas soluciones, solo necesitas obtener una cuenta en los servicios que usan y descargar la base de datos apropiada. O en su defecto pagar para acceder a los servicios en línea.

Ambos son muy útiles si no existe inconveniente económico. O si no se desea hacer muchos cambios.

Sin embargo, existen otras formas de bloquear por país en WordPress.

2. Con un CDN como Cloudflare

Si el sitio web en WordPress se encuentra detrás de un CDN como CloudFlare, puedes fácilmente limitar el acceso a ciertos países solo agregando un pequeño código al archivo functions.php que usa tu tema o con un plugin a medida.

Así, por ejemplo, se puede usar esa característica usando el siguiente código:

Con ese pequeño código, se bloquearán todos los clientes que visiten páginas dinámicas y que sean de los países en la lista «negra».

Algo muy importante que hay que indicar, es que las soluciones de plugins o de código como el mostrado no funcionarán siempre si hay un plugin de cache activado.

Esto se debe a que los plugins de cache, en la mayoría de los casos, crean páginas estáticas para enviar en vez de las páginas dinámicas.

Debido a esto, el código no se ejecutará. Pero si ese mismo usuario intenta acceder a la página de login, entonces sí será bloqueado.

3. Mediante una consulta a AbuseIPDB

En una entrada anterior hablé de como agregar la lista negra de AbuseIPDB a un servidor. Pero dicho servicio ofrece mucho más que solo la lista negra.

Cuando se consulta una dirección IP a su check endpoint, nosotros obtenemos toda una serie de información del cliente.

Esta información incluye datos como país de origen e incluso una calificación de cual probable es que trate de abusar de algún recurso.

Toda esta información es útil para evitar ataques o incluso fraudes para las tiendas en línea.

Así, con el siguiente script, nosotros podemos bloquear a un visitante tanto por su país como por su puntuación (si esta es mayor a 50):

Igualmente, para evitar realizar consultas de forma constante, guarda los resultados en un transient de WordPress. Así le generamos la menor molestia a los usuarios legitimos.

Pero, como se menciono antes, esto solo funciona en las páginas dinámicas. Aquellas que se encuentran servidas por el caché aún pueden ser visitadas por personas de los países bloqueados.

4. Bloquear por país usando la base de datos de GeoIP2

MaxMind ofrece la base de datos GeoIP2 Lite de forma gratuita. La cual se puede descargar desde su sitio web con tan solo registrarse.

Igualmente, ellos proporcionan un paquete con el cual se puede acceder a su base de datos usando PHP. Con la cual se vuelve muy sencillo el acceder a los datos.

Solo hace falta descargar el archivo phar o usar composer para agregar el proyecto a un plugin. Tras lo cual se puede agregar y usar de la siguiente manera:

De esta forma, estaríamos usando entonces ya usando la base de datos para bloquear a los visitantes de los países deseados.

Plugin de WordPress con GeoIP2

He desarrollado un plugin sencillo, el cual usa la base de datos de GeoIP2 para bloquear a los visitantes de los países seleccionados:

Su uso es extremadamente sencillo y viene tanto en español (España y México) como en ingles.

Para usarlo, solo hace falta instalarlo e ir a Herramientas > Bloquear por país. Solo debes de tener cuidado de no seleccionar el país en el cual te encuentras, o el sistema podría evitar que ingreses.

En caso de encuentres algún problema, puedes ponerte conmigo en contacto.

Conclusiones sobre como bloquear por país

Bloquear por país a un visitantes es relativamente sencillo. Aunque se necesita de herramientas adicionales para poder obtener la información necesaria para hacerlo.

La dirección IP por si misma no aporta esa información. Pero es fácil obtener detalles adicionales si se cuenta con los recursos necesarios.

Hoy en día prácticamente todo está a un API o Base de Datos de distancia.

The post [Guía] 4 formas de bloquear por país en WordPress appeared first on Endless Manifesto.

En esta pequeña entrada, hablaré de como hacer uso de dicha base de datos para proteger un servidor corriendo Linux. Y en mi caso Ubuntu.

La base de datos que ofrece AbuseIPDB nos permite saber todo un historial sobre una dirección IP. Cuantas veces ha sido reportada, por quien e incluso que tipos de ataques ha realizado.

Esta información es especialmente útil si contamos con otras herramientas como fail2ban. Esto para proteger de forma eficiente un servidor.

Pero a veces, no queremos consumir una dirección a la vez. Tampoco queremos solo reportar quienes están intentando vulnerar un recurso.

Es ahí en donde la lista negra de AbuseIPDB entra en acción.

¿Qué información contiene la lista negra de AbuseIPDB?

La lista negra, en pocas palabras, solamente contiene una lista de los clientes con mayor actividad. De los clientes con el mayor número de reportes desde múltiples fuentes.

Por lo cual se vuelve una gran herramienta a la hora de detener cualquier dirección que intente vulnerar un servidor. Ya que al saber su historial, es fácil de deducir que seguramente que lo harán.

Dicho recurso, al ser consultado, nos regresa una lista de hasta 10,000 direcciones altamente peligrosas para la versión gratuita.

Si bien no son todos los clientes mal intencionados, si son una cantidad importante. Nada despreciable considerando el tipo de actividad que realizan.

¿Cómo aprovechar esta lista?

Gracias a que AbuseIPDB ofrece puntos de acceso fáciles de usar, nosotros podemos acceder a la lista negra usando el siguiente endpoint: https://api.abuseipdb.com/api/v2/blacklist

Sin embargo, para poder consultarla debemos de estar registrados y obtener una llave API. Si no la tienes, puedes crearte una cuenta en minutos. Así puedes obtener to llave API.

Pero el truco real está en implementar directamente la lista en el firewall de cualquier servidor. Eso se puede lograr usando scripts y cron jobs. De esta forma, es posible actualizar la lista en el servidor una vez al día.

Para no sobrecargar el servidor, debemos usar las herramientas iptables e ipset. Ya que soluciones como fail2ban son simplemente muy lentas a la hora de agregar gran número de direcciones.

El programa ipset nos permite agregar cantidad de direcciones IP y manejarlas fácilmente mediante colecciones. Todo esto utilizando pocos recursos.

Un ejemplo práctico de la implementación

El agregar las direcciones conflictivas al cortafuegos es sencillo. En mi caso, he creado un script en python3 que lo hace.

Para ello, utilizo también una colección creada con ipset. La cual se limpia antes de cualquier actualización.

De esa forma, los clientes que ya no se encuentran en la lista negra de AbuseIPDB son descartados. Aunque es posible mantenerlos, para fines prácticos de esta ejemplo, no se explora esa posibilidad.

Así, este es el script que se corre cada día y que actualiza los datos desde AbuseIPDB:

Explicación del script de la lista negra

El script de python3 anterior realiza una serie de acciones antes de consultar a AbuseIPDB para agregar las direcciones. Se explican los puntos más importantes del programa:

#ejecuta: ipset flush blacklist
run([ipset_bin, 'flush', set_name])

Esta línea corre un subproceso, un comando, invocando a /sbin/ipset para indicarle que limpie la lista negra local de todos los ips que tiene en ella.

#ejecuta: ipset create blacklist iphash -exist
run([ipset_bin, 'create', set_name, 'iphash', '-exist'])

Si no existe una colección creada por ipset, esta será crea. Esta usará un método de hash ideal para direcciones aleatorias. Si la colección ya existe, no pasa nada.

#Consulta el API mandando las credenciales en las cabeceras
response = requests.get(blacklist_url, headers=request_headers)

Entonces, realizamos la consulta y obtenemos el grupo de direcciones que queremos agregar al cortafuegos. En este caso, los datos están en formato json y más adelante son convertidos para ser usados por el script.

#ejecuta: ipset add blacklist <direccion_ip> -exist
run([ipset_bin, 'add', set_name, client_data['ipAddress'], '-exist'])

Finalmente, procedemos a agregar las direcciones de la lista de AbuseIPDB en la colección. Con la opción -exist nos aseguramos de que, en el remoto caso de que exista un duplicado, no nos muestre algún error.

#ejecuta: iptables -I INPUT -m set --match-set blacklist src -j DROP
run([iptables_bin, '-I', 'INPUT', '-m', 'set', '--match-set', set_name, 'src', '-j', 'DROP'])

Esto es entonces lo que hace la magia. Con este comando le decimos al cortafuegos que use la colección que hemos creado para las conexiones entrantes. Si la IP que se intenta conectar está en la lista negra, simplemente será ignorada de forma silenciosa.

Recuerda, solo usa este comando la primera vez que ejecutes el script en la máquina o servidor. O solo cuando esta se haya reiniciado.

Agregando soporte para IPv6

La versión que se ha mostrado antes funciona bien cuando solo hay direcciones IP de la versión 4. Sin embargo, hay ocasiones en las cuales la lista negra de AbuseIPDB contiene direcciones IP de la versión 6.

Si bien el script no detecta el tipo de IP, esto no afecta el funcionamiento ya que simplemente esas direcciones no son agregadas y continua la ejecución.

¿Pero que pasa si también quiero bloquear esas direcciones?

Por fortuna, esto se puede solucionar fácilmente. Ya que tanto ipset como iptables tienen soluciones para estas direcciones. Junto con python3.

Para aceptar las direcciones IPv6, primero debemos de crear un set con la opción family definida en inet6. Esto, se vería así en la consola:

ipset create set_name iphash -exist family inet6

Con esto creamos el set para agregar direcciones de la versión 6 al cortafuegos. Traduciendo la instrucción a python, quedaría de la siguiente manera:

run([ipset_bin, 'create', set_name, 'iphash', '-exist', 'family', 'inet6'])

Pero aún queda un paso importante: ¿Cómo saber si una IP es IPv4 o IPv6? Eso lo debemos de saber antes de saber a cual lista se va a agregar la dirección.

Por fortuna, python3 tiene una librería llamada ipaddress que sirve para esos casos.

Usando esa librería, es fácil saber datos de una dirección IP. Solo hace falta hacer lo siguiente:

import ipaddress
ip_version = ipaddress.ip_address(remore_ip_address).version

Con esa librería, nosotros tenemos acceso a diversa información de una dirección. Esto en forma de un objeto.

Otro uso que le podemos dar a esta librería es para saber si una dirección es pública o no. Esto lo logramos usando el atributo is_global.

Agregando la detección IPv6 al script de lista negra de AbuseIPDB

Una vez que hemos resuelto este par de problemas, entonces nosotros podemos ponerlo todo junto en el script.

Con lo cual, nos debería quedar algo similar a esto:

Con este script, nosotros creamos los sets que necesitamos además de que se agregan de forma correcta a iptables.

Ojo, hay que recordar que un set de IPs de versión 6 requiere que se vincule usando el binario ip6tables en vez de iptables.

Igualmente, como está en el ejemplo, solo nos aseguramos de agregar al set todos los IPs que sean públicos. Esto usando el atributo is_global que da TRUE o FALSE dependiendo cada caso.

De esta forma evitamos que, por cualquier razón, se agreguen IPs privadas a la lista de elementos bloqueados del firewall.

Si bien AbuseIPDB.com tiene mucho cuidado en no agregar a su lista negra IPs que sean de carácter privado, siempre es bueno verificarlos.

Paso final: Crear un cron job para la lista negra

Hasta ahora todo bien. Ya tenemos un script que puede agregar al firewall direcciones IPv4 o IPv6, pero hasta este momento hay que correrlo manualmente.

Algo que ciertamente no es ideal en muchos de los casos. Lo mejor siempre va a ser que el mismo se ejecute de forma constante cada cierto tiempo.

Para eso, debemos de adaptarlo y agregarlo como parte de los trabajos del cron del sistema.

Pero para ello hay que tener en consideración algo: Los sets creados no son persistentes.

Esto significa que cada vez que se reinicie el equipo, estos van a desaparecer, por lo cual hay que volverlos a crear.

Este problema lo podemos solucionar de múltiples formas y una de ellas es el agregar un trabajo que se encargue de recuperar nuestra lista con cada inicio.

Con lo cual tendríamos dos scripts. Uno ejecutándose diario y otro solo al iniciar el servidor. Así podemos hacer algo tan sencillo como esto:

Puedes descargar estos archivos aquí:

Si has prestado atención, puedes ver que solamente se ha movido el código a una función (def) y que importamos en el primer script lo que necesitamos para llenar el set de ips.

De esta forma no necesitamos escribir de nueva cuenta el programa para ambos casos. Y así podemos agregarlo al cron usando el siguiente comando:

sudo crontab -e

Estando ya en el editor, deberemos de agregar las siguientes líneas:

0 3 * * * /full/path/to/importabuseipdbblacklist.py
@reboot python3 /full/path/to/loadabuseipdbonboot.py

Una vez hecho, ya estarán las tareas listas a ejecutarse cada vez que se reinicie el servidor, o una vez todos los días a las 3 de la mañana.

De esta forma, la lista negra siempre estará al día y cargada.

Nota: Ambos archivos, tanto importabuseipdbblacklist.py como loadabuseipdbonboot.py deben de estar en el mismo directorio.

Conclusiones sobre agregar la lista negra de AbuseIPDB

Agregar la lista negra de AbuseIPDB es relativamente sencillo. En especial si cuentas con las herramientas correctas.

Hay muchas formas de prevenir que clientes con mal comportamiento encuentren un servidor. Pero bloqueándolos antes de que tengan oportunidad es una de las mejores.

El usar herramientas como firewalld no siempre es lo mejor, por limitaciones que tiene la misma. A veces hay que hacer las cosas con comandos más cercanos al núcleo.

Finalmente, hay que recordar que esta solución no es realmente «persistente», ya que la lista desaparecerá cada vez que se reinicie el sistema.

Aunque se soluciona fácilmente, como lo es creando cron jobs, existen diversas formas de solucionarlo. Pero en cada caso, todo depende de las propias necesidades que tengamos.

Sin embargo, hay que preguntarse: ¿Qué tan seguido se reinicia un servidor? En mi experiencia, no mucho.

Pero quizá podamos dejar para otro día la implementación de un mecanismo persistente.

The post [Tutorial] Como agregar la lista negra de AbuseIPDB al Firewall appeared first on Endless Manifesto.

En pocas palabras, Cloudflare puede causar un ataque DDoS.

¿Qué sucede con Rocket Loader?

Rocket Loader es una característica en estado beta de Cloudflare. Su principal objetivo es mejorar la velocidad de un sitio web. Eso lo hace bien.

Sin embargo, recientemente he estado observando problemas con este.

Por ejemplo, cada vez que he enviado datos de formulario, he observado un número inusual de conexiones. Al principio pensé que se trataba de un ataque.

Pero mientras más busque, es que me fui percatando de que había un problema entre el plugin Wordfence y este servicio de Cloudflare.

¿Qué es lo que sucedía con WordFence?

Haciendo la historia corta, empece a ver que mis sitios web generaban errores y que el servidor en el cual estoy «colapsara». Al punto de que necesitaba el reiniciarlo a mano.

Algo que no debería de suceder.

Cuando finalmente comencé a ver los registros de apache, comencé a observar un alto número de llamados a un mismo URL con lo siguiente:

/?wordfence_lh=1&hid=...

Observé que se hacían estos llamados en oleadas de 20 a 50 conexiones por segundo. Algo que este servidor no podía aguantar.

Al menos no con la configuración presente.

Pero al estar indagando es que fui encontrando de que no era el único el cual estaba sufriendo de este problema de WordPress con Wordfence y Cloudflare.

¿Qué fue lo que pasó entre Rocket Loader y WordPress?

En un hilo de la comunidad de Cloudflare, se habla de cambios que se están haciendo a Rocket Loader.

Después de todo, se entiende debido a que es software en estado beta.

Sin embargo, en este caso esto significó problemas que causaron la caída de un servidor. Mientras no es grave, si implica que el riesgo existía todavía.

En su momento se menciono que el problema había sido resuelto. Eso era cierto, ya que desde la semana pasado no volví a ver el problema… hasta ayer.

¿Como soluciono la caída de WordPress por Rocket Loader?

La forma más sencilla de evitar este problema es desactivando por completo Rocket Loader. Como característica beta, no debería de ser usada indiscriminadamente.

Menos en entornos de producción.

La ventaja es que esta característica viene desactivada por defecto. Sin embargo, si la han activado por ti, puedes desactivarla así:

Ingresa a Cloudflare > Elige el Dominio > Speed > Rocket Loader

Ahí podrás apagar esta característica. De esta forma quizá ya no veas problemas en tu servidor.

Conclusiones sobre Rocket Loader

Cloudflare no me había dado grandes problemas desde que lo uso hace ya más de 5 años, si no es que más.

Sin embargo, esta característica, que promete mucho, me ha hecho tener que vigilar un poco mejor las opciones que tengo activadas en dicho servicio.

Todos queremos que nuestros sitios web sean rápidos… sin embargo, a veces eso nos hace el usar software en estado beta, como Rocket Loader, cuando no están listos para producción.

Yo ya sentí en carne propia algunos de sus problemas. Quizá la vuelva a activar cuando este más madura o con Page Rules.

Pero ya veremos.

Actualización sobre Rocket Loader

Recientemente volví a activar Rocket Loader tratar de obtener más datos sobre este problema. Y así poder reportarlo de forma correcta.

Y es que, tras mirar los registros del servidor, ya no encontré las referencias a Wordfence como antes. Pero a admin-ajax.php. Lo cual cambia un poco el panorama.

La última vez que sufrí el problema fue el pasado 27 de mayo.

Mi problema ahora es que no he podido duplicar este bug. No me ha vuelto a suceder. Es plausible de que necesite esperar un tiempo ante de poder reproducirlo. Aunque igualmente es plausible de que haya sido corregido correctamente.

Pero eso lo veremos en los próximos días.

The post Problemas con Rocket Loader de Cloudflare appeared first on Endless Manifesto.