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
jail).

This is what the standard ssh jail looks like:

[ssh]
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
203.0.113.20 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
measure.

This is how fail2ban’s log file looks like:

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

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 ***

[Definition]
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
parameters).

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
the QUERY STRING.
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.

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.

Referencias:
Puede encontrar más información:

https://www.owasp.org/index.php/Guide_to_SQL_Injection

https://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)

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.

-    Data Loss Prevention Tech Support Engineer (Windows Server Administration, Networking, SQL, Active Directory, Linux)
-    NetBackup Tech Support Engineer (Windows Server Administration, backup software)
-    PGP Tech Support Engineer (Windows Server Administration, Linux, Microsoft Exchange Server, DNS & Networking, SQL, Encryption is a Plus)
-    Guardian Edge Tech Support Engineer  (Windows Server Administration, Microsoft Exchange Server, DNS & Networking, SQL, Encryption is a Plus)
-    Enterprise Vault Tech Support Engineer (Microsoft Exchange Server, SQL, Windows Server Administration)

Beneficios:
- Swiss Medical PREMIUM (plan más alto)
- A partir del 6to mes, facultad paga (carreras de grado/postgrado, incluye libros)
- OPCIONAL: Plan de acciones (15% rebajadas).

- Combi (ida y vuelta)
- Horario flexible
- Certificaciones pagas (Microsoft, CISCO, IBM, VMWare, Linux, etc)

Requisitos:

- MUY buen ingles (excluyente)
- Conocimientos técnicos
- CV en ingles (excluyente)

* lo jodido: cookies de seguimiento, publicidad y terceras partes.

(gracias Ewarik por el rapido analisis!)

LINKS:
http://www.ico.gov.uk/~/media/documents/library/Privacy_and_electronic/Practical_application/advice_on_the_new_cookies_regulations.pdf

http://blog.statcounter.com/2011/05/the-cookie-directive/

En esos mails, el chabon dice que le aviso a la ONTI (no se a que mail habra escrito, pero nadie lo conoce) y al arcert (area donde yo trabajo, TAMPOCO LLEGO NINGUN MAIL).

Y despues salta alguien que no se quien es, en twitter (https://twitter.com/ochoigualaD/status/63978046650191873) diciendo: “injec7or hell esta poniendo en riesgo la infraestructura nacional! Donde esta el arCert? Y la ONTI? Y @buanzo? Y la moto?” – Mis respuestas pueden verlas en twitter.com/buanzo

La posta es que el arcert no tiene por que responder ningun mail (cosa no aplicable en este caso, ya que NI SIQUIERA recibimos nada del tal injec7or…)

Hay una politica MUY BIEN redactada en ArCERT sobre que procedimiento seguir en caso de advisories que son dados a conocer al publico general, y eso, les aseguro, esta en proceso. Uno de los items de dicha politica es contactarse con el que envio la data a las listas publicas, el tal anonymous coward injec7or.

En 1996 yo encontre una seria vulnerabilidad de ejecucion de codigo remota en el sitio de la presidencia. Y le mande un mail al admin, CON MIS DATOS REALES. Ese admin el dia de hoy todavia es mi amigo, y todavia trabaja en el estado.

Si el flaco hubiera mandado los mails a ONTI y arcert como el dice, no hubiera tenido necesidad de usar un pseudonimo.

Saludos.

Inicio el reclamo en paypal, se que me van a ayudar, pero sepanlo: ARMYTECH = garcas

ACTUALIZACION: paypal me devolvio la plata, pero la gente de armytech mas que ofenderse no hizo nada. pesima comunicacion. ojo, esto fue siempre asi, incluso cuando gaste plata comprandoles a ellos. por algo tienen tanto exceso de seguridad en el local que tienen.

La idea es un espacio donde compartir tips, precios, conocer gente, organizar asados

Vegetarianos incluidos!

Dale, pasen, copense

Estimados amigos y familiares,

Acá les dejo el video que filmamos en donde vivimos junto a Raffaella, para dar lugar a un repaso sonoro de las mejores canciones del disco de reversiones electrónicas del cantautor Jorge Drexler. Luego de 3 años y mucho esfuerzo, amor y una sinfonía de sentimientos vertidos en ceros y unos (en conjunto con el uruguayo Nacho Benedetti) está terminado y en producción (física).

Acá pueden escuchar partes de esas canciones mezcladas para el objetivo (lógico y deducible) de promocionar el disco antes de su venta en formato vinilo, cd y digital (itunes y demás!)

http://www.youtube.com/watch?v=Deda-wGAhSQ

Los abrazo desde una suiza con hoy 26°!

Besos y abrazos!

f.

Pero de golpe dije: DAMN, esto va a servir para que haya robo de identidad mucho mas avanzado. O falsificacion de comunicaciones, etc.

Usando ingenieria social, seguramente se pudiera lograr que una persona DIGA palabras que un abusador necesite. Incluso para inculpar a alguien.

Va a ser muy necesario que tengamos eso en cuenta.

Epero Blaving agregue algun “procesador de efectos” para la voz!