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.

Los errores SIGSEGV en PHP aparecen una mañana

Durante unos días libres que tuve, realice una actualización de PHP desde 7.2.12 (aproximadamente) a la ultima versión disponible de PHP: 7.3.1

Todo salio bien en ese momento. Incluso las cosas funcionaban sin problemas, pero eso cambiaría a la mañana siguiente.

Fue entonces cuando este sitio web me arrojo un error 503. Así como otros más en esta VPS corriendo ubuntu.

Al revisar en los archivos de errores, en busca de alguna causa, solo encontraba lo siguiente:

(104)Connection reset by peer: [client XX.XX.XX.XX:XXXX] AH01075: Error dispatching request to : 

AH01067: Failed to read FastCGI header

Al mirar más de cerca, resulto que Apache servia contenido estático sin problemas. Solo las páginas generadas por PHP mostraban el error.

Cuando revise en los registros de PHP, la siguiente línea aparecía múltiples veces:

WARNING: [pool XXXXX] child XXXX exited on signal 11 (SIGSEGV - core dumped) after 30.977656 seconds from start

Este error de SIGSEGV en PHP significaba que había sucedido una Violación de Acceso de memoria (segfault o segmentation fault) por parte de PHP.

¿Cómo era esto posible? ¿Qué lo estaba causando?

Una de las soluciones temporales que encontré fue el usar el siguiente comando:

systemctl restart php7.3-fpm

Pero esta era una solución temporal. Ya que al poco tiempo el problema volvía a suceder. En algunos casos tan pronto como a los pocos segundos.

Esto se estaba volviendo una pesadilla.

Apache2, prefork y el modulo PHP7.3: ¿Origen del problema?

Durante mi investigación, detecte algo que pase por alto cuando actualice PHP a su versión 7.3: Me había agregado un nuevo módulo y cambiado el modo MPM de Apache.

El modo lo podemos ver con el siguiente comando en ubuntu:

apache2ctl -V

¿Eso explicaba el problema?

De lo primero que me percate es que ese nuevo módulo, llamado solamente «PHP7.3», necesitaba que Apache2 corriera en modo Prefork.

No entendí por que de este movimiento, pero no era el cual había configurado en el servidor: Event.

Por lo cual procedí a desactivar PHP7.3 y cambiar Prefork por Event, ejecutando lo siguiente:

sudo a2dismod php7.3
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
systemctl restart apache2
systemctl restart php7.3-fpm

De lo primero que me pude percatar, es que los errores de SIGSEGV en PHP bajaron dramáticamente con esto.

Aunque pronto descubriría que estos estaban lejos de desaparecer.

El error SIGSEGV en PHP da tregua, pero no por mucho

PHP 7.3 funciono de forma normal por algunos días. Pero eventualmente el error volvió a aparecer.

En los registros volvía a ver la señal 11 de SIGSEGV en PHP, lo cual me indicó que el problema tenia muchas posibilidades de seguir apareciendo.

Aunque era menos común, esto significaba que podía suceder en cualquier momento.

Buscando más a fondo, encontré quizá lo más profundo del origen del problema:

segfault at 6c6f4320 ip b4b92b37 sp bfe93df0 error 4 in opcache.so[b4b82000+6d000]

Por fortuna, comencé a notar que no era el único con este problema. Usuarios del panel Plesk también reportaron este problema. E incluso dicha empresa no está recomendando PHP7.3 por el momento.

Lo cual, parece indicar que no hay una solución definitiva por ahora.

Entonces, ¿Cómo solucionar las caídas de PHP?

Como comenté antes, PHP constantemente arroja un error segfault o SIGSEGV el cual interrumpe la ejecución de cualquier recurso dinámico.

Sin embargo, esto se soluciona cuando se reinicia el servicio. Hacerlo manualmente no es una solución aceptable. Y crear un cronjob no me parece una buena idea.

Pero hay alternativas que ya ofrece PHP de forma nativa.

Por ejemplo, nosotros podemos editar el archivo php-fpm.conf (ya que es el modo FPM el cual fallaba para mi) y configurar lo siguiente:

/etc/php/7.3/fpm/php-fpm.conf :
emergency_restart_threshold = 3
emergency_restart_interval = 1h
process_control_timeout = 10s

Con esto, hacemos que PHP este al pendiente por errores. Y cuando sucedan 3 errores en una hora, se reiniciará automáticamente.

De esta forma, el servicio se restablecerá de forma automática sin necesitar nuestra intervención.

Estos valores pueden ser fácilmente cambiados de acuerdo a tus propias necesidades. Solamente recuerda reiniciar el servicio de php-fpm una vez hagas cambios.

Para concluir

Si bien actualmente PHP7.3 parece tener problemas con su sistema de cache interno, con las correcciones adecuadas es posible usarlo sin problemas.

Pero hay algo muy importante que resaltar. Por ahora es mejor el mantenerse en PHP7.2 o tener múltiples versiones instaladas si es posible.

Ya que, a diferencia de la versión más nueva, PHP7.2 está mucho más maduro y este tipo de problemas son mucho más raros.

En mi caso, todavía sigo buscando que es lo que causa el error de SIGSEGV en PHP 7.3, y aunque sospecho que puede causarlo… no tengo una solución definitiva.

Lo que si, espero que esta pequeña guía le sea de utilidad a alguien. Ya que encontrar una solución, aunque parcial, fue una búsqueda de varios días.

Actualización y solución definitiva

Tras haber estado sufriendo el problema de los errores SIGSEGV por mucho tiempo con PHP 7.3, estos finalmente dejaron e suceder.

Sin embargo, la solución puede no ser tan trivial.

Resulta que con PHP 7.4, los errores simplemente desaparecieron. He estado observando los registros de PHP de forma continua por este error desde la actualización, pero esta no ha vuelto a suceder.

Lo cual me hace pensar que el problema no esta presente en PHP 7.4.

Si esta dentro de tus posibilidades, actualizar hacia la versión 7.4 de PHP es lo mejor. No solo trae más características si no que es hasta más seguro.

En caso de que no sepas como actualizar, pregunta con quien lleva tu hospedaje, este debe de poder ayudarte.

The post Error SIGSEGV en PHP 7.3 [Solución definitiva] appeared first on Endless Manifesto.

While paying USD$300 for recovering your files sounds reasonable… do not do it.

It’s very likely that the authors of the virus will just take your money and give you nothing back. That is the way that it usually works.

What does this WannaCry?

Long history short: It will encrypt all files you use on your computer. Then, it will ask the user for a ransom in order to «decrypt» them.

Basically, it will make your files garbage and ask you for money to turn them back to normal.

The problem is that once encrypted, you rely on a criminal to have your files restored. And it’s very likely that they will just walk away with your money.

What can I do then?

 There are some things you can do in order to try and recover yourself from this virus. Yet, it will never beat to wipe clean your hard disk and reinstall all your stuff.

In my case, I personally like a much more proactive approach. Things that I feel like common sense when you are working with computers and other… vulnerable software and hardware.

1. Keep yourself up to date

WannaCry only affects Windows installations. That is why you need to keep it up to date whenever possible with the «windows update» feature.

An updated system is safer and more healthy.

Of course, in this very special case, even a fix was offered to Windows XP and other «retired» systems.

The best option for you, in the long run, is to simply upgrade yourself to the most modern version of windows. If that is not possible, then Linux makes a fine choice to keep nasty stuff from infecting you and it is very easy to use nowadays.

2. Make backups often

Doing backups may be a headache if you have large numbers of files, like me. But doing them should be a habit to keep yourself safe.

Be that a failing hard disk, a crashing system or just the WannaCry ransomware, a backup keeps your data safe. And lessens the damage.

One can make backups in many ways. For example, Dropbox, Google Drive or a Personal Cloud are fine options if you want to keep a few files safe.

But when you have a large amount, like 10GB or more, having a portable hard disk is a better idea.

In my case, I use a program named «FreeFileSync» that allows me to make «mirrors» of the folders I want. With it, I only copy into the hard disk any different and new file, saving a lot of time.

3. Do not open strange emails

 Always check the extension of the files that other people are sending you. And more importantly, never open attached files, or click links, from people you do not know.

A file ending with a «.exe» or «.vbs» can potentially be a virus. Even if sent from a person you do not know. Heck, you even should not open any file with such extensions unless you know what you are doing.

Never trust what you receive in your inbox. Save for the cases where you openly asked to receive things.

Sounds harsh, but you can keep away a lot of problems that way. Do not open the links or files contained in an email, from that bank where you do not have an account, or that looks quite suspicious.

4. Keep your passwords strong

It is hard to keep track of all the accounts and its passwords as time goes by. And sometimes, we usually think that just setting our password as «password1234» is safe enough.

Wrong.

This is where a password manager become handy. And I personally like «KeePass» for such task, as the generated file is encrypted and can only be opened if you enter the correct password.

Having your passwords in the cloud or in a notetaking software can work too. But I am not fond to such solutions and like an extra layer of security.

5. Keep an antivirus up and running

Maybe should have had this one listed before. But, well… to have an antivirus, even a free one, is always a good idea. As an extra layer of defense.

I personally like the «Avast» one. As it is not intrusive, seems to spend little resources and can be configured to update itself without yelling at me to do so.

6. Other measures

Those are the most basic ways one can protect itself from a virus like the WannaCry. While no system is totally safe, even Linux has vulnerabilities… even Unix, we can do a lot of things to decrease the risk to a minimum.

Other ways include being behind a firewall or deactivate SMB, heck, even making your computer not to listen to certain ports. But that is far from the scope from this post.

Do not give up

As the years have come by, I have had my computers fall to all sorts of virus and stuff. You always recover yourself. But you need to be ready before hand.

I have always loved to have a dual booting at my computers, hence the featured image.

Having a separate EXT4 partition for Linux, while a sacrifice of space, can keep me safe when something goes horribly wrong at Windows. And it usually happens.

Probably I should then spend more time at my Linux install if the risks of virus become more and more prominent. Just a shame that I do not have all the tools I need there… yet.

The post WannaCry and stay safe from it appeared first on Endless Manifesto.