Introducing fail2ban-zmq-tools: a fail2ban clustering solution based on zeromq

So, you might recall this article of mine:

Proactive Protection Enhancements for fail2ban, part 1

From June 2011. Ouch.

Anyway, as I have always wanted to cluster up all my fail2ban servers, especially without opening security holes between them, I cooked up these set of scripts that use the AWESOME zeromq messaging API:

I called them fail2ban-zmq-tools, also known as fail2ban-cluster. It consists of a Publisher, which receives messages from Monitor instances and broadcasts them to Subscriber instances.

You can clone up the repository by checking out this github web repos:




Artículos relacionados:


I love music.

Even before I even loved technology, I loved music.

You know, it’s not really clear in my mind. I close my eyes and music and equipment/technology go hand in hand. Playing the piano: it was an electric organ, full of lights and knobs and pedals and STUFF. And one of the first things I ever enjoyed doing with a computer was NOISES. Or music. Whatever.

That’s how I learned about ADC/DACs (Analogic-to-digital converters, and viceversa). A magazine here in Argentina decided to ship a printer-port (parallel, lots of pins, wide as hell. damn ESDs!) that allowed applications to abuse an interfaced that converted data into audio. You would plug the other end of the interface into your stereo’s inputs. Oh, that’s called RCA? Good to know. I hate those.

And so, trying to find something that could help me enjoy that interface, other than games… I found MODEDIT.

That was called a tracker. It had 4 channels I believe. Supported .SAM format samples, which you could then use on those four channels, to produce a .MOD file, that you would play somehow.

I used to program tunes using BASIC, playing thru the internal computer speaker. A tracker such as MODEDIT was a higher abstraction layer. Not TOO up there, but interesting enough.

And I played the guitar a lot. And came across more computer software for music production. And then synthesizers. Sequencers. OMG.

This happened:

Artículos relacionados:

10 tips to become a Hacker

Originally published on:
Titles. Heh.

Today I found myself in the middle of a long email conversation with a young student from Germany. Someone related to fail2ban, one of the projects I contribute to.

We share a love of music, and security. Somehow, I ended up opening up, and telling my story. How I got into music, programming, Linux, security, and government work.

Professionalism is weird when it arrives, I know.

For instance, I began with Linux in 1994/1995. I was 12/13 at that time. I did not pursue an university degree, as IT Engineering here in Argentina was not in the state it currently is (and still needs MUCH more. How I would love to go back to teaching.).

I was best off by teaching myself! When I was 16-20, I used to write a lot of articles for the local Linux magazine, which I “funded” with other 2 editors (Damian Alonso, Facundo Arena) plus the editorial management staff, of course, from MP). I was in charge of the “Guru” section, programming, networking, etc. So my writings, as there weren’t many spanish-based articles (You can find some of them in at that time, at least in Argentina, ended up in the minds of many people. – And some even in use by one of the national universities, as reading material for their programming / operating systems courses. They called me when I was 19 to teach at that university. I was fresh out of high-school with a diploma in Electronics. I started the CBC, but dropped out. Today, I am really looking forward to finding a career. Probably not in IT, though. Something to expand my mind.

So, you want to become a Hacker. Here are some tips, right out from my personal experience.

#1 Get it into your mind. Hacker means ethics. Hacker means curiosity. Hacker means a desire to improve things. Hacking is fun. And healthy. As I usually say in my talks: “Does any of you drive a car? Does any of you drive REALLY WELL? Oh, so I guess you are probably a killer”.

Oh, so you are good with the computer. That means you are a criminal, right?

Get it straight. Any person can become a criminal. It is not hard. You just need to be a bad person. You can blame any other bunch of factors, but in the end, it means you are evil. Mistakes, that is something else. And you will make many… growing up. And then some. With or without the computer knowledge.

#2 You will need to open up. You can use any OS to do lots of things, but the more multi-platform knowledge you gain, the better. Use Windows. Use Linux. Use more than one OS. This is far easier to do today. Between your game console, your computer and your tablet/smartphone, you already have 2+ OSes, surely.

#3 Break things. Break yourself, too. Pursue a different area of knowledge, a different interest, such as music playing, literature, languages. Try new stuff. Enjoy the experience.

#4 Love those around you. That means respect, too. You will make it easy for them to support your interests, especially growing up. Yeah, I’m sure most people reading this on Linkedin are older, but luckily, some parent is reading this and might share the link.

#5 Find a team to share knowledge with. I suggest a 2600 meeting. – You will find what areas of IT knowledge most interest you this way, too. For instance, I love defense, forensics and all things networking/comms, especially authentication and data sharing / analysis. But I get bored with the offensive side of things.

#6 Programming is a must. Stick to a limited number of languages at first. I would suggest python, C, assembler and some C# (it is quite an awesome language from which you will learn a lot). Try to attack your code. Debug as crazy. Attempt to understand why stuff breaks. In 1998 I coded a multiuser BBS for Linux, in plain C. It was the way to understand all things about Linux, as I had to learn IPC, sockets, processes, input handling, locks, filesystem, terminal capabilities, session control, etc, etc. Making it crash, and debugging it, allowed me to understand how an exploit would work. Learning how to code an exploit is also extremely useful, as it gives you the “other way round” knowledge of operating systems and code execution.

#7 Help others. I cannot emphasize this enough: your experience, your knowledge, has no value if you do not find a way to help others, in any way, using any methodology. Be loyal.

#8 Do not allow yourself to be used by evil people. Information gathering, one of the stages of “how to attack a problem”, can be applied socially. Avoid bad actors. But you will find yourself that “know your enemy” is also valuable. Remember I mentioned ethics?

#9 Get out in the open. Analyze your surroundings. Travel. Technology is everywhere, but subtlety is beautiful. Balance.

#10 You will one day die. Try to make the best out of life. Think about what you will leave behind. That is the real, the ultimate hack.

Artículos relacionados:

Abusing the Past (A 2600 Article, published Volume 32 Number One)

This article I wrote for 2600, was first published in 2600 Magazine (, Volume Thirty-Two, Number One, Spring 2015. As it has now been in physical circulation for some time, I now publish it online.


Abusing the Past
by Buanzo

DISCLAIMER: If you do evil shit with this information, I hope something really bad happens to you. Information is free, but people are human.

It has been quite a long time since my last article, so I’ll keep it short.

In this day and age, there are mass scanning tools and several easy-to-query databases that make it
a simple thing to find sites with vulnerabilities. Hackers and other agents with all hat-colors use them every day to do their jobs. I will present you today
a very simple technique that will, when certain special circumstances are met, allow you to scan the past for vulnerabilities.

When we want to have a website, we obtain a [sub]domain name, point it to some web hosting server’s IP, and configure it to serve that
website. We also get DNS service somehow. I am sure you’ve done this before, so I’ll skip those details. So now, is running on server A.

Yay, we got a website! By the way, it is Joomla or some other CMS like wordpress, etc.

The days/months/years pass, and we find ourselves in the need to move the website to another server, for whatever reason (luckily, cause we have so many
visits the old server cant handle them). The new website is configured on the new server, the DNS is updated, and voila, visits now arrive at the new server.



If we go to Netcraft, and check some domain name using their tools, we MIGHT find the hosting history of a website. Yes, used to run on server A,
then server B, now server C! And, wow, thats weird, the old servers are still up and running.

So, MIGHT still be configured in one of those servers. You know how hosting companies [dont] do their homework sometimes 馃槈

So, an attacker could fire up a scanner, and by any means available, target thru the older IP addresses, and scan our OLD WEBSITE[s],
which, of course, we no longer keep updated (maybe not even the server, for that matter…). And you know what outdated usually means: holes. Lots of them.

And holes lead to lots of things: remote code execution, data exfiltration, resource control.

An Nmap NSE script could be written to scan some domain name’s hosting history, and, essentially, abuse the past.

Go. Check your hosting history. Don’t say I did not warn you. 馃槢



Artículos relacionados:

Falla de escalacion de privilegios en procesadores intel 64-bit

El CERT de Estados Unidos ha notificado de una falla en los procesadores Intel que podria permitir a atacantes tomar control de MS Windows (r) y otros sistemas operativos. El fallo fue notificado a traves de un advisory liberado esta semana. Se podria explotar la vulnerabilidad para ejecutar codigo malicioso con privilegios de kernel, segun el blog de Bitfedender. ‘Algunos sistemas operativos de 64 bits y software de virtualizacion ejecutandose en equipamiento con chips Intel son vulnerables a un ataque de escalacion de privilegios.’. ‘La vulnerabilidad podria ser explotada para elevacion de privilegios local, o para escapar de una maquina virtual al host fisico.’. – Segun el articulo, los sistemas operativos afectados incluyen a Windows 7, Windows Server 2008 R2, versiones 64 bit de FreeBSD y NetBSD, asi como los sistemas que incluyan el hypervisor Xen.”.

Original click aqui

Artículos relacionados:

Chau amigo

Artículos relacionados:

POR FIN! Enigform ya anda en Firefox 10+

Bueno, despues de BOCHA DE TIEMPO, finalmente pude actualizar el codigo de Enigform (mi extension firefox que extiende HTTP con algunas cositas de OpenPGP divertidas como por ejemplo inicio seguro de sesiones).

Ahora voy a tunearlo y hermosearlo un poco porque tiene bocha de llamadas dump() para hacer depuracion 馃槢 y mas de una de esas es insegura 馃槢

Asi que, LOS QUE QUIERAN PROBAR LA BETA de Enigform 0.9.0 pueden descargarla de – No lo pongo como link asi piensan dos veces antes de hacerlo!

Artículos relacionados:

Proactive protection enhancements for fail2ban – Part 1


Introducing fail2ban, and first steps towards sharing attacker’s IP
by Arturo ‘Buanzo’ Busleiman

Fail2ban is a lovely python-based tool written by Cyril Jaquier that
monitors different logfiles for lines matching regular expressions.聽 From
those lines it extracts the attackers IP address, and runs a command passing
that as a parameter.

In more simple terms, it detects when your SSH (or other service) is
“attacked”, and then proceeds to firewall the attacker.

We could start discussing about false positives here, specially for UDP
based services or log-injection vulnerable daemons, but I’d like to focus on
a special usage scenario: what if I manage multiple servers? Should I wait
for the same attacker to target each of my fail2ban-monitored servers?

Maybe I could share the attacker’s IP, collected from a brute-force attempt
to SSH on server1, with the rest of the servers I manage. Or with my
friends’ servers. Or maybe with everybody through twitter? Well, maybe
everybody is too much and possibly a bad idea if fail2ban is detecting false
positives, or spoofed IP addresses. But it could also help out if you manage
your own small or medium sized group of servers.

If you think this might interest you, then keep reading.

Architecturally, fail2ban is one main process (the fail2ban-server). It
needs a so-called “jail” definition (a group of filter+action+logfile
configuration items), a filter definition (regular expressions for a certain
kind of logfile, such as sshd or apache error log), and an action
definition (what to do when a filter detects an attacker, in that certain

This is what the standard ssh jail looks like:

enabled = true
port聽聽聽 = ssh
filter聽 = sshd
logpath聽 = /var/log/daemon.log
maxretry = 3

As you can see, it defines if the jail is enabled or not (active or not),
what destionation port[s] it will block for the attacker, what filter
(regex) is to be used to determine (or ignore!) attackers, and which
logfile[s] it will monitor. Also, the number of times the same attacker must
be detected in a pre-defined time period for the action to be executed.

What does that mean? Easy: If, by any reason, you or another user mistypes
the password and is trying to access the server from a non-whitelisted IP
address, instead of trying more than 3 times in a row, it should wait a
couple minutes and try again. Having a detection threshold helps avoiding
false positives.

Fail2ban has the ability to ignore certain IP addresses or netblocks, or
have different actions for each jail. This level of flexibility is what
interest us for the purpose of this article.

Standard fail2ban configuration contains 20+ actions, spanning
iptables, ipfw, shorewall, etc. More than 30 filter definitions, including
regexes for apache, sshd, php-url-fopen, proftpd, pam and more.

For a detailed fail2ban-configuration document, I recommend you just
download the package and read its filters, actions and jails. It’s very self
explanatory. A knowledge of regular expressions will come in handy,
especially if your POSIX-compatible system has differences in the logfile
format for the services you’re trying to protect.

* How to share the attacker’s details

Lets imagine we own a small web-hosting company, providing ssh access to our
limited number of customers. Or a big web app load-balanced and with
failover protection spanning 10 geographically-distant dedicated servers.

Also, let’s assume we have a standard ssh jail configured to run iptables,
matching the sshd filter.

If server1’s fail2ban detects, for instance, that an attacker with IP address is attempting to brute-force our ssh service
(note: that address is part of the TEST-NET-3 netblock, allocated by
RFC 5737 for usage in documentation), then the attacker will be firewalled
using iptables.

But only on server1.

Should I manually filter the attacker on the other servers? Well, it’ll take
a long time. Or I could write a script to do it. Or maybe I could try and
work with what fail2ban gives me: lots of flexibility.

The first time I started thinking about this “fail2ban-cluster” tool, I
thought I should design a new “action”, one that would not only run iptables
but also notify the other servers.

But that’d be a waste of resources, not to mention TIME.

So I decided to use a different approach. Fail2ban has a lovely log file,
that tells us when a certain attacker is banned, and then un-banned after a
configurable amount of time.

Maybe I could write a filter to read fail2ban’s log itself, with an action
to spread that IP address, possibly using lynx, or curl, to as many other
servers as I wanted, by means of some authenticated http service. And I’d
run that on top of my inter-server virtual private network, for good

This is how fail2ban’s log file looks like:

2011-05-01 15:23:56,380 fail2ban.actions: WARNING [ssh] Ban
2011-05-01 15:38:57,641 fail2ban.actions: WARNING [ssh] Unban

As you can see, we have entries for Ban and for Unban events. But I do not
want to notify unban events, because different servers could have different
how-long-to-ban-the-attacker policies. I just want to notify BANs.

So maybe a simple regular expression like: ‘\ Ban\ <HOST>$’ would take care
of detecting BANs only. And it does. Fail2ban provides the fail2ban-regex
tool, to test regular expressions against a sample log line or file.

I ran it like this: fail2ban-regex /var/log/fail2ban.log ‘\ Ban\ <HOST>$’

It yielded the expected results. The special <HOST> tag in the regex is what
tells fail2ban how to extract the IP address from there. Currently, it
supports IPv4 but the fail2ban team and contributors are working on IPv6
support as I write.

So, now I can write a fail2ban filter configuration file, such as this:

*** contents of /etc/fail2ban/filter.d/f2bcluster.conf ***

failregex = \ Ban\ <HOST>$
ignoreregex =

*** end ***

But we have no action. We can’t write a jail definition without an action!

An action file contains definitions of commands to run: once at the start of
fail2ban, once at the stop, once before each ban event, and the ban action
itself, and the unban one. It also includes a default name, port and
protocol definition, in case the jail config file does not define them.

Inside each action definition you can use special tags, similar to the
<HOST> one used in filters. For actions, we have <ip> (holds the attacker’s
IP obtained from <HOST>), <name> and <protocol> (used for some iptables

When the commands are run, each of those special tags will be replaced by
the values we expect.

As an exercise to the reader, or you can wait for the next article in this
series, I’d like you to write an actioban definition, with these hints:

a) the actionban should be a simple bash script
b) the bash script will use lynx/curl to send an authenticated http request
c) the request will go the server2, server3, etc. As many times as required.
d) the request will be received by a simple python-based (or php…) script
that REQUIRES http authentication. It will receive the attacker’s IP from
e) The http python/php/whatever script will NOT run iptables, but write to a
log file.

As you probably guess, the log file will be monitored by that server’s own
fail2ban instance, by means of a more classic filter definition.

And remember: security is a state of mind.

About me

I’ve been using GNU/Linux non-stop since September 1995, when I
was 13 years old. Currently working in the IT security area as a consultant,
sysadmin and forensics specialist. I’m an OWASP Project Leader (check out
Enigform and mod_openpgp for Apache). I play the guitar, and currently
experiencing with electronic music and livecoding with fluxus. I’m a geek.

Artículos relacionados:

SQL Injection…

Es un tema que afecta a la gran mayor铆a de los sitios web del mundo. Suena exagerado decirlo as铆, pero si lo analizamos desde la perspectiva de que es un problema que muchas veces los programadores resuelven 煤nicamente donde/cuando han sido atacados, y en el futuro vuelven a escribir c贸digo inseguro, tal vez entonces no suene tan descabellado.

Mucha gente escucha “inyecci贸n sql” y piensan que es un vector de ataque que permite 煤nicamente inyectar sentencias SQL con el objeto de modificar la informaci贸n de una base de datos.

Lo cual es verdad.

El problema es que la inyecci贸n sql, y dependiendo del sistema de base de datos utilizado por el backend del aplicativo web, permite incluso la ejecuci贸n de programas en el servidor donde se encuentra la base de datos a la cual se accede, indirectamente, v铆a web.

La principal soluci贸n es sencilla: desconfiar del usuario. O mejor a煤n, SABER que el aspecto de un sitio web, sus formularios, su tecnolog铆a AJAX, en fin, el dise帽o del sitio web no limitan de ninguna manera lo que el atacante puede enviar al servidor web.

驴Qu茅 quiero decir con eso? Much铆simos dise帽adores web incorporan alg煤n tipo de validaci贸n de datos, pero si esta validaci贸n ocurre 煤nicamente v铆a JavaScript en el NAVEGADOR del usuario, dicha validaci贸n para un atacante de poco conocimiento es sinceramente f谩cil de evitar.

Por ejemplo, filtrar un campo num茅rico para que solo admita caracteres del 0 al 9 utilizando 煤nicamente JavaScript, pasa a ser 煤nicamente algo “funcional” para el verdadero usuario, y una inexistente limitaci贸n para el atacante. Con instalar la extensi贸n Tamper Data para Mozilla Firefox, al momento de hacer clic en “enviar” a dicho formulario, podemos modificar a nuestro antojo casi cualquier aspecto de la consulta HTTP “fabricada” por el formulario. Y poner una comilla simple y ver que resultados no esperados (por ejemplo, un mensaje de error del motor de base de datos) surgen de dicha manipulaci贸n.

Si la validaci贸n de datos ocurriera TAMBI脡N del lado del aplicativo web, en el nivel que sea, dicha t茅cnica no ser铆a aplicable.

Puede encontrar m谩s informaci贸n:锘


Y ahora, para divertirse un poco… piensen que abusar parametros, cookies, cualquier dato que pueda de una manera u otra ser controlado por un navegante es potencialmente un punto de inyeccion, no solo de SQLi, sino para XSS, RFI, etc.


Artículos relacionados:

Buscamos una Nieta

Pasen por este post de taringa. Si pueden votenlo, asi logra ser sticky.


Artículos relacionados: