Block attacker IP addresses, four ways

If you run WordPress you’ve seen these in your web server logs: - - [29/Oct/2020:13:58:41 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" - - [29/Oct/2020:13:58:44 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" - - [29/Oct/2020:13:58:48 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" - - [29/Oct/2020:13:58:52 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" - - [29/Oct/2020:13:58:55 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" - - [29/Oct/2020:13:58:58 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-"

Fucken scanners just slamming xmlrpc.php looking for a way in. When this happens CPU usage just goes through the roof for as long as the scan lasts and it could be five minutes, could be six hours, could be all week; before it ends. The gods help you if you’re paying by CPU usage.

So you have to block access to the file. You could just block all access to XML-RPC but doing this will prevent the WP mobile app from working.

We’ll just block that specific IP address but we need to be quick about it; just do a quick one liner on the terminal before the OS just topples over and becomes completely unresponsive or worse.


This should work for any Linux distribution that has iptables out of the box which is basically all of them.

# iptables -I INPUT -s -j DROP
  • -I: Insert the rule as the first rule to be applied in the INPUT chain. You could use -A (append) but the sooner we get rid of that traffic the less work the CPU has to do.
  • -s: Source address, in this case, which belongs to Tencent.
  • -j: jump to the DROP target. If you use the REJECT target you’re just creating more work for the CPU.

Documentation here but the Ubuntu how-to is far more useful in getting people started.


As it is part of both FreeBSD and OpenBSD base installations it should be enabled in /etc/rc.conf but from reading the (almost useless) documentation and looking around the web You need to fuck around with pf.conf first, then you can manipulate the table. This is the first result on the web when you search for “pf block ip address”. So no one-liner that can save your life.

Edit /etc/pf.conf and add

table <badhosts> persist
block on fxp0 from <badhosts> to any
  • Create table named badhosts, and set it to be persistent in kernel memory
  • Block, on interface fxp0 (you’ll want to change this), traffic from rules in the badhosts table to any destination.

Once you have this you can manipulate the table from the command line with pfctl

# pfctl -t badhosts -T add
  • -t means pfctl will manipulate the badhosts table
  • -T will show statistics
  • add address to the table

Fucken hell FreeBSD documentation is the fucken worst. Dryer than Melania Trump’s libido. Now, reading through the OpenBSD pf documentation it looks like you can do

# pfctl -t badhosts -T add

Which will create the badhosts table automatically without having to fuck around with /etc/pf.conf. Don’t know if this will work on FreeBSD though.


It is part of the FreeBSD base installation so it does depend on ipfw being enabled in /etc/rc.conf but it looks like you can go

# ipfw add deny all from to any
  • Add rule denying any and all fraffic from to any destination

At least these rules are succint and easy to read. Whomever wrote the documentation seemed to pay more attention to usage at least.

Still, fuck FreeBSD.


Super easy now that PowerShell is built into Windows itself:

PS C:\WINDOWS\system32> New-NetFirewallRule -DisplayName "Block traffic from" -Direction Inbound -LocalPort Any -Protocol Any - Action Block -RemoteAddress
  • -DisplayName: The human-readable name of the firewall rule
  • -Direction: Can be Outbound or Inbound. We want Inbound obviously.
  • -LocalPort: Going with any ports because fuck crackers.
  • -Protocol: Same, block all port
  • -Action: Block traffic
  • -RemoteAddress: Specifying only

The documentation for the commandlet is super nice. No, I’m not typing ‘cmdlet’.

The old way involved so, so manny clicks. PowerShell makes it easy.

Now all of the previous bits of code cease to have any effect after a system reboot so if you want the rules to be permanent… don’t. Blackhats will just scan from different hosts and different networks so blocking an IP address permanently is just unproductive.

A better solution is to use fail2ban:

There is also CrowdSec but I haven’t personally used them.

This post came to be cos I spent 30+ minutes trying to figure out how to block traffic on a FreeBSD host and their documentation is just… inscrutable. Should you ask for help in their forums you’ll just get told to RTFM.

You end up going in circles, consuming yourself in rage and frustration which does not feel nice. Rage-posting is where it’sat.

I want a drink and it’s not even 0700 yet

On this here blog I use a few things to help secure everything down and avoid issues, namely, nginx location blocks disallowing access to resources, fail2ban tracking nginx logs to prevent people hammering server or trying to do improper things, and the “Limit Login Attempts” WP plugin.

A combination of all these broke access with the wordpress mobile app. Ended up having to disable the wordpress fail2ban jail and altering some of the nginx directives.

This is going to be a pain in the ass to debug cos the wordpress app doesn’t have any kind of proper error messaging, urgh.

Flickr, interrupted

Flickr deprecated its support of the MetaWeblogAPI back in 2014 but it’s been working okay so far so I never thought of updating the thing since it was working Just Fine™ and I wasn’t going to start fucken about with this. I’m okay with the state of the thing as it is right now but it’s probably time to start looking at other solutions. Since I—

And then stuff at work went to shit while I was typing this, so I’m getting this from where I left off.

Don’t remember where I was at. I’ll pick up later. Shit to do.

Press This

WordPress removed the “Press This” bookmarklet because:

  • WordPress developers are fucking idiots.
  • WordPress developers fucking hate you, the user.

Most of the links I put up on this site were usually through the bookmarklet. “We just want to increase security”, they say, then break the functionality without a proper equivalent in place.

They’re probably friends with Firefox developers, who also like to break with the past without regard to their users.

But what do users know, right? Developers always know better.


I done went and got SSL on this here site by way of Let’s Encrypt. It was pretty easy.

Not so easy was the run up to get it installed:

  • Update Debian with latest packages
  • Realize Debian is now on oldstable (jessie)
  • Update Debian to stable (squeeze)
  • Kinda-sorta fix it (aptitute still suicides on forking)
  • Run $ sudo certbot --nginx and marvel at how far we’ve come along

The last time I tries setting up SSL was a total pain in the ass, and it only got me a self-signed certificate that all of the browsers kept complaining about.

Yay for one thing taken off the bucket list. As an aside, I changed the permalink structure cos long URLs that use a date/time format are annoying and hard to remember. I got the idea for switching from here. I hear it plays hell with your SEO but I don’t particularly care about it here. Everyday at work I suffer from URLs that mean one thing for one person but something entirely different for someone else depending what they are doing.

Annoying as fuck, let me tell you.

Now I just need to figure out a plugin that will let me type stuff into the WP editor in markdown/commonmark, and not make the plugins kill themselves.

Big Spam dump!

Large collection of default spam-comments from a slimy SEO tool.

This morning, I woke up to find that someone who was new to the tool (or unclear on the concept) had left a spam with all of the default comment messages in it, dumping the full database of anodyne comments intended to fool both the spam-filter and the human operator into thinking that the sender had read the post and was replying to it.

This should be helpful in blocking future spam.

WordPress 2.7

Logré actualizar sin que Gengo la hiciera de tos. Aquí esta lo que hice:

  1. Respalde archivos y base de datos.
  2. Desactive todos los plugins excepto Gengo.
  3. Actualice.
  4. Re-configure Gengo y aplique los cambios.
  5. Limpie el cache del navegador.
  6. Mire el sitio. Funcionó.

Si no funciona, trata moviendole a las opciones de Lenguage, pero recuerda de limpiar el cache del navegador cada vez que lo hagas. Gengo le da una galleta al navegador para que recuerde las cosas.

WordPress 2.7 en sí se mira bastante mono. La interfaz para escribir entradas es mucho mejor, razón suficiente para hacer el brinco.

WordPress 2.7

Managed to upgrade without having Gengo bitch out. Here’s what I did:

  1. Backed up both DB and files.
  2. Deactivated all plugins except Gengo
  3. Upgraded
  4. Re-configured Gengo settings and applied changes.
  5. Cleared browser cache.
  6. Viewed site. It worked.

If it doesn’t work, try playing around with the Language settings but remember to clear your browser cache every time you do this. Gengo gives a cookie to your browser to make it remember stuff.

WordPress 2.7 itself is pretty good. The writing interface is much better, reason alone to make the jump.

Estimado Gengo

Por favor apresúrate en madurar, por que haz demostrado lo que una plataforma bloguera multi-lenguaje es capaz de hacer cuando se implementa apropiadamente. No puedo comenzar a imaginar lo que mi vida en WordPress seria sin haber perdido incontables horas en restaurar bases de datos jodidas cuando no te gusta el nuevo plugin en el directorio de plugins y haces berrinche tenerte alrededor para dejarme bloguear en dos idiomas sin muchos inconvenientes.


Dear Gengo

Please hurry up in maturing, for you have shown what a truly multilingual blogging platform is able to do when implemented properly. I cannot begin to imagine what my WordPress life would be without having sunk countless hours in restoring fucked up databases when you don’t like the new plugin in the plugins directory and throw a tantrum having you around to let me blog in two languages without too much hassle.



The good people at Día Siete are releasing the magazine in PDF files. Hopefully they’ll release old editions as well.

They’re also changing the format of the site, going from a simple advertisement space for the magazine’s contents into a space with its own additional content that is not in the magazine! If it all looks a bit familiar it’s because they’re using WP 2.5.1, w00t

They’re good, and getting better.


La buena gente de Día Siete están soltando la revista en archivos PDF. Ojala y en una de esas se animen a soltar las ediciones previas.

También se encuentran cambiando el formato del sitio, pasando de un simple espacio publicitario del contenido de la revista a un espacio con contenido agregado que no viene en la revista! Si de repente se ve un poco familiar el asunto es por que están usando WP 2.5.1, w00t.

Van bien, y mejorando.

Security in WordPress

I’m not saying WordPress isn’t secure, but the perception seems to be

“WordPress is not secure”

It’s said in TechCrunch, it’s called out to Matt, JD of Get Rich Slowly had big trouble, and there are a lot of tips and tutorials. The Codex entry on Hardening WordPress is missing some stuff… but the perception keeps turning more and more negative. If it keeps up like this some other platform will come along claiming to everyone to be more secure than everyone else and a lot of people will migrate just because of that.

I feel to avoid this the focus of WordPress 2.7 should be security. We already have a stable and flexible platform to establish and maintain blogs, so now it must become a secure platform.

Seguridad en WordPress

No es que diga que WordPress no es seguro, pero siento que la percepción en general es:

“WordPress no es seguro”

Lo dicen en TechCruch, se lo reclaman a Matt, el de Get Rich Slowly tuvo broncas fuertes, y hay un chingo de tutoriales y tips por todos lados. A la entrada en el Codex acerca de como endurecer WP le hacen falta algunas cosas… pero ps la percepción sigue tornándose mas y mas negativa. De seguir así va a llegar alguna otra plataforma clamando a diestra y siniestras que es mas segura que los demás y muchos migraran solo por eso.

Siento que para evitar que esto suceda el énfasis de WordPress 2.7 debe ser la seguridad. Ya tenemos una plataforma estable y flexible para establecer y mantener blogs, por lo que ahora debe convertirse en una plataforma segura.

Advanced WYSIWYG modification

I’ve been using this plugin for a while now to take the place of WP’s default editor because it’s too plain and it’s missing some features. Problem was after installing the plugin it looked like crap and I ended up modifying it as well.

Now I made somewhat more extensive modification and added lots of things while keeping buttons included in the default editor — like the “More” button for example — y expanding the available options.

You start with this:

Wordpress WYSIWYG original

Then it changes to this after installing the unmodified plugin:

Advanced WYSIWYG original

It’s pretty obvious keeping that setup is out of the question, so I hacked it a bit, removed some things and added others… but I recently got tired of having to change to the code editor to use stuff like the “More” button or remove formatting

After a bit of poking I ended up with this:

Advanced WYSIWYG mod

As you can see we now have two rows of buttons but keep WP stuff like the “More” button and the spellchecker and keep plugin stuff like the foreground/background modifyers… and get some extras like the table editor and the formatting eraser.

If you’re interested you can download the modified file here. If you install and activate it the way it is you’ll end up with something like this:

Modified Advanced WYSIWIG with some missing features

To have all the available features you need to do some work:

  1. First download TinyMCE here. Doesn’t matter if it’s the tarfile or the zip, they contain exactly the same files
  2. Uncompress the file and go to the plugins directory. Using FTP upload the “table” and “xhtmlxtras” directory to the location wp-includesjstinymceplugins on your host. Directory “wp-includes” is located on the WordPress root folder.
  3. Go write a new post and voilá. If you had already uploaded and activated the modified plugin you must refresh the page manually using the reload/refresh button on your browser, or you can press F5

With that done you now should have the full set of buttons. If you paid some attention you should have seen many more plugins for TinyMCE. You can add those functions but you need to do it manually editing the plugin PHP file and uploading the corresponding directories to the TinyMCE plugins folder. One that could be useful for sites that constantly use the same code over and over is the “template” plugin. After creating — and making sure it works — the template just fill up the blank spots and you’re done, like event sites or WordPress MU. If you want to add your own buttons you’ll want to look at the plugin documentation and the button reference for the available buttons.

I don’t think I broke anything when I made the modifications and I tested it on WP 2.1 and 2.1.2. For Suggestions and yelps use the comments.

Modificacion – Advanced WYSIWYG

Desde hace tiempo venia usando este plugin para sustituir el editor visual de WP 2.0 por que editor normal esta bien pinche simple y le hacían falta cosas. Problema fue que a la hora de instalarlo acabe modificándolo también por que se veía de la chngada.

Ahora me avente una modificación más amplia y le agregue bastantes cosas manteniendo varios de los botones que vienen con la versión de WP — el botón de “More” por ejemplo — y expandiendo las opciones.

Primero se comienza con esto:

Wordpress WYSIWYG original

De ahí pasa a esto al instalarse el plugin sin modificación:

Advanced WYSIWYG original

Resulta obvio que dejarlo así resulta bastante estorboso. así que le moví y le quite unas cosas y agregue otras… pero recientemente me enfade de tener que cambiar a webo al editor de código para echar a andar cosas con la función “More” de WP o eliminar formatos.

Después de un rato de moverle termine con esto:

Advanced WYSIWYG mod

Yeap, como ven tenemos dos renglones de botones, pero se mantienen cosas de WP como el botón de “More” y la revisión de ortografía además de tener los botones para modificar colores de texto y de fondo… además de que le agregue el editor de tablas y la goma para eliminar formatos.

Si les interesa pueden bajar el archivo modificado desde aquí. Si lo instalan y activan así como va terminaran con algo así:

Modified Advanced WYSIWIG with some missing features

Para tener todos los botones es un poco mas trabajoso:

  1. Primero hay que bajar el TinyMCE desde aquí. No importa si es el tarro o el zip, ambos contienen exactamente los mismos archivos.
  2. Extraer el archivo e ir al directorio de plugins. Con FTP hay que subir los directorios “table” y “xhtmlxtras” al directorio wp-includesjstinymceplugins en el servidor. El folder wp-includes esta dentro del directorio raíz de WordPress
  3. Crear un nuevo post y voilá. Si ya habías subido y activado el plugin modificado tienes que refrescar la pagina manualmente presionando el botón de “reload” o “refresh” en tu navegador, o presionar F5.

Con eso deben quedar con el set completo de botones. Si se fijaron hay muchos mas plugins para el TinyMCE, las funciones se pueden agregar pero se tiene que hacer manualmente agregando el código necesario al archivo PHP del plugin y subiendo los directorios correspondientes al directorio de plugins de TinyMCE. Uno que en lo personal considero practico para sitios que constantemente usan el mismo código una y otra vez es el de templates. Solo seria rellenar los datos y ya, como para paginas de eventos o algo en WordPress MU. Si alguien quiere agregar sus cosas mas le vale que lea la documentación para los plugins y la referencia de botones disponibles.

Creo que no rompí nada al hacer las modificaciones y fue probado en WordPress 2.1 y 2.1.2. Mentadas y sugerencias en los comentarios.


Recently noesh changed her template, just in case you hadn’t noticed. Thanks to WordPress’ flexibility in this regard, changing themes is pretty easy to do.

But along the way there were a couple of issues: The first one is, when changing, pretty much all of the custom code noesh manually added to the template was lost; the second one is the new template uses widgets. When the WordPress widgets are activated all the code that’s not part of the widget code – usually in the ‘sidebar’ file – is ignored.

As I figure it, there are a few ways to use the old code>

  • 1. Copy the XHTML code from the old template to the new template
  • 2. Look for updated versions of installed plugins and install those new versions, hoping they have widget functionality built into them
  • 3. Create new widgets from the existing plugins, modifying the plugin code to widgetize it.
  • 4. Use the old code in a widget-like way by way of an additional plugin or script

All of them have their benefits and their drawbacks. In my case I went for the last option, for it entailed the least time spent, because I don’t know much PHP to write plugins/widgets for wordpress and I’m not about to spend my energy learning how. Maybe some other time.

With this decided, I looked for a plugin that would let me do what I had in mind. After a while I found this plugin, which lets you use any PHP file in the template directory and add its contents as a widget in the configuration page.

Second step was to create a PHP file in which I put a fragment of code. In noesh’s case, it’s a call for the AJAX shoutbox which was originally on the sidebar code file:
< ?php jal_get_shoutbox(); ?>

In ruidoz’s case, it’s a call to the phrases script.

For all this to work, the file must begin with ‘widget_’ or ‘widget-‘ as the filename. Upload it to the server and save it on the active template directory. If it’s put somewhere it just won’t work. After that the necessary amount of theme widgets have to be activated on the widget configuration page. Read the plugin instructions for more details.

With these steps all those plugins that had to be called from the template sidebar file can be added as widgets without having to muck around the code itself. Helps a lot with themes that had the widget coded added to them and with plugins that don’t have widget functionality built into them yet.

This is great for PHP… but what if you had a bit of XHTML code? Not to worry; all that needs to be done is to add it as a text widget. This is useful for fragments of code like a flickr badge. For this the theme widgets plugin doesn’t have to be installed, since the function is included with the widgets plugin itself. For example, noeshtiosita’s badge now looks like this:
HTML Fragment.

The total time spent? Just about an hour and a half, which – for the effort – is nice. Another good thing is it lets you change theme quicker and easier since no coded needs to be added or removed from the template code. Just move the ‘widget_’ or ‘widget-‘ files to the new template’s directory and reactivate them at the widget configuration page.

Now, keep in mind this is pretty much a temporal solution until most plugins have widget funcions implemented. Until then, this is something to do to avoid code headaches.


Recientemente noesh cambio de template, por si no se habian dado cuenta. Gracias a la flexibilidad de wordpress, cambiar de template es bastante facil.

Pero aqui hubo un problemita que consta de dos partes: La primera es, que al cambiar, se perdio mucho del codigo que noesh habia agregado manualmente y la segunda esque el nuevo template usa widgets. Cuando se estan usando los widgets de wordpress todo el codigo que esta puesto manualmente – por lo regular en el archivo ‘sidebar’ del template – es ignorado.

Para poder usar todo ese codigo existente hay varias formas de poderlo hacer:

  1. 1. Copiar el codigo XHTML del template viejo al nuevo.
  2. 2. Buscar versiones nuevas de los plugins e instalarlas para agregar esas funciones ya como un widget.
  3. 3. Crear widgets nuevos en base a los plugins existentes, modificando el codigo del plugin para “widgetizarlo
  4. 4. Usar el codigo viejo a manera de widget usando algun plugin/script adicional.

Todas tienen sus beneficios y sus contras. En mi caso me fui por la ultima opcion para terminar rapido, por que no se gran cosa de PHP ni como hacer plugins/widgets para wordpress y ahorita tampoco estoy como para ponerme a aprender a hacerlo.

Ya con todo esto decidido, me puse a buscar algun plugin que me permitiera hacer lo que tenia en mente. Despues de buscar un rato, di coneste plugin, que agarra cualquier archivo PHP en el directorio del template y permite agregar funciones adicionales como un widget en la pantalla de configuracion.

Segundo paso fue hacer un archivo PHP en el cual puse un fragmento de codigo. En el caso de noesh, es una llamada para el AJAX shoutbox que originalmente estaba en el codigo del template:
< ?php jal_get_shoutbox(); ?>

En el caso de ruidoz, es una llamada para el script de frases.

Para que esto funcione, se tiene que crear un archivo que comience con ‘widget_’ o ‘widget-‘. Hay que subirlo al servidor y guardarlo en el directorio del template que esta activo; si se mete en cualquier otro directorio no va a funcionar. Despues hay que activar la cantidad necesaria de ‘theme widgets’ en la pantalla de configuracion de widgets. Leer las instrucciones del plugin para mas detalles.

Con esos pasos todos esos plugins que habia que llamar manualmente desde el codigo del template pueden quedar como theme widgets sin estar jugando con codigo. Ayuda mucho con templates a los que el codigo para widgets les fue puesto despues de su creacion y para plugins que aun no son actualizados con funciones de widget.

Esto es util para PHP… pero que hay que hacer cuando se tiene un fragmento de XHTML? En lugar de agegar el fragmento al codigo en si nada mas hay que ponerlo en un widget de texto; bastante practico para cosas que solo son un fragmento de codigo como los flickr badges. Para cosas asi no hace falta el plugin de theme widgets, la funcion ya esta incluida con el plugin de widgets. Por ejemplo, el codigo del badge de noesh quedo asi:
HTML Fragment.

El total de tiempo que inverti en esta solucion? Mas o menos hora y media, lo cual – para el esfuerzo – es bastante bueno. Ademas es una opcion que permite cambiar de template con mas facilidad, puesto que ya no hay que agregar y eliminar codigo del template manualmente. Lo unico que se tendria que hacer es mover los archivos ‘widget_’ o ‘widget-‘ al template nuevo y reactivarlos en la pantalla de configuracion.

Esto es mas que nada una solucion temporal, pero en lo que todos los plugins que agregan contenido a la pagina final sean actualizados, es algo para evitar dolores de cabeza.